Architecture d'intégration de l'intercom-service
L'intercom-service est une infrastructure petite mais critique de l'écosystème openEDU. C'est un proxy et courtier résidant dans le navigateur qui permet la communication entre applications — sélecteurs de fichiers, création de salles de visioconférence, connexion unique silencieuse entre applications et navigation de portail. En détenant la session OpenID Connect de l'utilisateur et en l'exposant au reste de la suite via un intermédiaire de confiance, il fait en sorte qu'un catalogue de services déployés séparément se comporte comme un espace de travail cohérent.
Ce qu'est l'intercom-service
L'intercom-service est un proxy léger qui s'exécute dans le contexte du navigateur de l'utilisateur. Chaque application participante intègre l'intercom-service sous forme d'iframe et communique avec lui via postMessage. Comme l'iframe vit sur l'origine de l'intercom-service, elle peut détenir des informations d'identification et un état de session que les applications individuelles ne peuvent pas directement partager entre elles — l'iframe agit comme un courtier de confiance au nom de l'utilisateur.
Cette conception maintient délibérément l'intercom-service léger. Il ne stocke pas de données applicatives ; il assure la médiation de la navigation, de la session et des intentions inter-applications entre des applications par ailleurs isolées par la politique de même origine du navigateur.
Les fonctionnalités qu'il fournit
Dans toute la suite, les applications s'appuient sur l'intercom-service pour un ensemble commun de fonctionnalités au niveau du navigateur :
- Connexion silencieuse — transmission de jetons OpenID Connect entre applications sans étape de réauthentification visible par l'utilisateur.
- Navigation de portail — récupération de la structure de navigation centrale afin que chaque application affiche le même menu de portail.
- Sélection de fichiers — ouverture d'un fichier du service de stockage de la suite dans une autre application.
- Salles de visioconférence — création de salles de conférence depuis une application collaborative.
- Déconnexion par canal de retour — coordination de la fin de session dans toutes les applications afin qu'une seule déconnexion mette fin à toutes les sessions.
Ces fonctionnalités sont le liant qui fait qu'une plateforme multi-services semble intégrée plutôt qu'une collection de sites web sans rapport.
Intégration avec la couche d'identité
L'authentification est centralisée sur Keycloak, qui sert de fournisseur OpenID Connect de la suite. L'intercom-service participe à ce realm via son propre client OIDC, configuré pour la convention de nommage de revendications de la plateforme (la revendication opendesk_username). Comme l'intercom-service détient la session OIDC, il peut effectuer une connexion silencieuse au nom d'une application subordonnée : l'application redirige vers l'intercom-service, le courtier échange la session stockée contre des jetons, et l'application continue sans inviter l'utilisateur.
Par défaut, le client OIDC est provisionné via le processus de bootstrap Keycloak de la suite, de sorte que ses revendications sont contrôlées centralement et de manière cohérente avec le reste de la plateforme. La déconnexion par canal de retour est coordonnée via le même flux OIDC, de sorte que la fin d'une session à un endroit se propage à toutes les applications qui s'appuient sur le courtier.
Ce que l'intercom-service met en relation
L'intercom-service est configuré avec l'ensemble des applications de confiance qu'il met en relation, et la suite active exactement les intégrations dont chaque déploiement a besoin. Dans la plateforme openEDU, on trouve notamment :
- Stockage de fichiers — les services de fichiers Nextcloud et OpenCloud, permettant la sélection de fichiers inter-applications et l'accès silencieux.
- Groupware — le backend groupware OX App Suite, avec prise en charge facultative de la pile Grommunio là où elle est activée.
- Wiki — le service XWiki.
- Communication — le déploiement Matrix (Synapse), câblé pour la messagerie et la vidéo, avec l'intercom-service configuré pour le serveur Matrix et son hook d'application-service.
La plateforme considère la liste des backends du courtier comme opt-in : un déploiement active les intégrations qu'il exécute réellement, de sorte que l'intercom-service reflète toujours la sélection concrète des services de l'instance plutôt qu'un catalogue fixe. Cela reflète la conception modulaire de la plateforme, où chaque service peut être activé ou désactivé indépendamment.
Comment les applications consomment le courtier
Les applications rejoignent le courtier en intégrant l'iframe de l'intercom-service et en le pointant vers les points de terminaison du courtier. En pratique :
- Messagerie (Element) est configurée avec les URL de navigation et de connexion silencieuse de l'intercom-service, de sorte que le client de messagerie affiche le portail partagé et se connecte silencieusement aux côtés du reste de la suite.
- Notes utilise l'URL de base du courtier comme point de terminaison d'intégration pour les comportements de session et de navigation inter-applications.
Le modèle est cohérent : une application déclare un petit ensemble d'URL d'intégration pointant vers l'intercom-service, et le courtier gère les préoccupations partagées de session et de navigation en son nom. Aucune application n'a besoin de sa propre logique de fédération ou de session.
Modèle de déploiement
L'intercom-service s'exécute comme une charge de travail Kubernetes gérée via la configuration Helm/helmfile de la plateforme, aux côtés des autres services de la suite :
- Il est empaqueté comme une image conteneur standard sur une base Alpine légère plutôt que d'exiger une image système spécifique au service, de sorte qu'il se déploie sur n'importe quel cluster Kubernetes sans dépendances spécifiques à la plateforme.
- Il s'exécute de manière durcie — non-root, système de fichiers racine en lecture seule, capacités Linux supprimées et profil seccomp restreint, conformément à la posture de sécurité du reste de la suite.
- Il expose un point de terminaison de santé pour les sondes de vivacité et de disponibilité Kubernetes.
- Son état de session est conservé dans la couche de cache partagée basée sur Redis de la plateforme.
- Il s'exécute derrière l'ingress de la plateforme, protégé par la même configuration TLS et ingress que chaque autre service.
Comme il détient l'état de session et relaie des jetons, l'intercom-service est traité comme un composant sensible à la sécurité : il est provisionné avec le même durcissement et la même gestion des certificats que les services liés à l'identité de la suite.
Relation avec l'amont
L'intercom-service est maintenu en amont par le projet openEDU CE et empaqueté pour l'environnement de collaboration unifié. openEDU déploie le même intercom-service et le configure pour la convention de nommage de revendications et la sélection de backends de la plateforme éducative. L'extension du courtier par la plateforme pour la pile éducative — ajout d'un support de stockage de fichiers au-delà de l'édition communautaire et configuration des backends groupware, wiki et communication pour son déploiement — est documentée dans l'article communautaire Étendre l'intercom-service.
Pour en savoir plus
- Vue d'ensemble de l'architecture système — l'architecture complète de la plateforme
- Architecture d'identité et d'authentification — comment l'OIDC et la fédération SAML sont gérés
- Architecture de sécurité — comment les données de session et d'identité sont protégées
- Étendre l'intercom-service — l'article communautaire sur les intégrations relayées et la gouvernance
L'intercom-service est ce qui fait qu'un catalogue de services déployés indépendamment se comporte comme un espace de travail unique — un petit courtier portant une grande partie de la charge d'intégration de la plateforme.
