1. Introduction

Imaginez qu'un membre de l'IREX souhaite accéder à la plateforme de supervision ACRA, déployée sur le réseau interne. Doit-il créer un nouveau compte ? Mémoriser un mot de passe supplémentaire ? Attendre qu'un administrateur lui ouvre des droits manuellement sur chaque outil ?

La réponse devrait être non — et c'est précisément ce que permet la fédération d'identité. Grâce à elle, un utilisateur authentifié par l'IdP de l'IREX peut accéder directement à ACRA, sans créer de compte supplémentaire, parce que les deux systèmes se font mutuellement confiance.

Cet article explique ce qu'est la fédération d'identité, pourquoi elle est devenue incontournable dans les architectures modernes, et comment elle fonctionne concrètement à travers le protocole OpenID Connect (OIDC).

2. Qu'est-ce que la fédération d'identité ?

La fédération d'identité est un mécanisme qui permet à deux organisations — ou deux domaines techniques distincts — d'établir une relation de confiance entre leurs systèmes d'identité respectifs. Un utilisateur appartenant au domaine A peut ainsi accéder aux ressources du domaine B, sans créer de compte dans B : son identité est reconnue grâce à cette relation de confiance.

Il est important de ne pas confondre la fédération avec deux notions proches :

• La gestion centralisée des identités (LDAP, Active Directory) : un annuaire unique centralise les comptes d'une seule organisation. Il n'y a qu'un seul domaine, pas de relation inter-systèmes.
• Le Single Sign-On (SSO) : un utilisateur s'authentifie une fois et accède à plusieurs applications du même domaine. Il y a toujours un seul fournisseur d'identité (IdP).
• La fédération d'identité : il existe au moins deux IdP distincts, chacun appartenant à un domaine différent, et ces IdP établissent une relation de confiance formelle pour se reconnaître mutuellement.

Dans le cas du projet ACRA : l'IREX dispose de son propre IdP (Keycloak IREX). La plateforme ACRA dispose du sien (Keycloak ACRA). Ces deux IdP appartiennent à des domaines distincts. Pour que les membres de l'IREX accèdent à ACRA sans créer de compte supplémentaire, Keycloak ACRA est configuré pour faire confiance à Keycloak IREX. C'est de la fédération.

3. Pourquoi la fédération d'identité est-elle essentielle ?

Dès qu'une organisation déploie une plateforme destinée à des utilisateurs issus d'un autre domaine, ou intègre un service externe dans son écosystème, plusieurs problèmes apparaissent immédiatement :

• Prolifération des comptes : sans fédération, chaque nouvelle plateforme exige la création d'un compte séparé — avec les risques associés (mots de passe oubliés, comptes non désactivés après départ d'un collaborateur).
• Fragmentation de la gestion des accès : révoquer les droits d'un utilisateur qui quitte l'organisation demande d'intervenir sur chaque système indépendamment, ce qui génère des oublis et des failles.
• Incohérence des politiques de sécurité : chaque système gère ses propres règles de mot de passe, d'expiration de session, de MFA — sans cohérence d'ensemble.
• Expérience utilisateur dégradée : jongler entre plusieurs identifiants pour accéder à des outils du même environnement professionnel est contre-productif et source d'erreurs.

La fédération résout ces problèmes en maintenant chaque organisation maître de son propre annuaire, tout en permettant aux ressources d'un domaine d'être accessibles aux utilisateurs d'un autre, de façon contrôlée et traçable.

Dans le projet ACRA, cela se traduit concrètement : si un membre de l'IREX quitte l'organisation et que son compte est désactivé sur Keycloak IREX, il perd automatiquement l'accès à ACRA — sans qu'aucune action soit nécessaire côté ACRA.

4. Bref historique

Les systèmes d'information n'ont pas toujours communiqué entre eux. Chaque application maintenait longtemps sa propre base d'utilisateurs, sans aucune interopérabilité.

Les annuaires centralisés comme LDAP ont constitué une première avancée en regroupant les identités au sein d'une organisation. Mais LDAP reste un annuaire interne : il ne définit pas de mécanisme pour établir une relation de confiance avec un système externe.

SAML (2002) a introduit le concept de fédération inter-organisations, permettant pour la première fois à deux entités distinctes d'échanger des assertions d'identité signées. SAML reste présent dans le monde de l'entreprise, mais sa verbosité XML et sa complexité de mise en œuvre ont poussé l'industrie vers des alternatives.

C'est là qu'intervient OpenID Connect (OIDC), publié en 2014 au-dessus d'OAuth 2.0. OIDC standardise l'authentification pour le web moderne : il repose sur des tokens compacts au format JWT, s'intègre naturellement avec les APIs REST, et est supporté nativement par des solutions comme Keycloak, Entra ID ou Okta. C'est aujourd'hui le protocole de référence pour la fédération d'identité — et celui utilisé dans le projet ACRA.

5. Fonctionnement d'une fédération OIDC

5.1 Les acteurs

Une fédération OIDC met en jeu trois types d'acteurs :

• L'IdP source : le fournisseur d'identité de l'organisation à laquelle appartient l'utilisateur. Il détient les comptes, gère les mots de passe et émet les tokens. Dans ACRA, c'est Keycloak IREX.
• L'IdP broker : un fournisseur d'identité intermédiaire qui ne gère pas directement les comptes, mais fait confiance à l'IdP source et sert de relais vers les applications. Dans ACRA, c'est Keycloak ACRA.
• Le fournisseur de service (SP) : l'application qui délègue l'authentification à l'IdP broker. Dans ACRA, c'est Grafana.

5.2 Le flux d'authentification fédérée

Lorsqu'un membre de l'IREX accède à acra.dev.onesi.ca, voici ce qui se passe, de façon transparente pour l'utilisateur :

1. Grafana redirige l'utilisateur vers Keycloak ACRA pour s'authentifier.
2. Keycloak ACRA, configuré comme broker OIDC, redirige l'utilisateur vers Keycloak IREX — l'IdP de son organisation.
3. L'utilisateur saisit ses identifiants IREX habituels sur la page de connexion de Keycloak IREX.
4. Keycloak IREX valide les identifiants et retourne un ID token signé (JWT) à Keycloak ACRA.
5. Keycloak ACRA vérifie ce token, reconnaît l'identité de l'utilisateur, et émet à son tour un token à destination de Grafana.
6. Grafana accorde l'accès, avec les rôles correspondant aux attributs transmis dans le token.

L'utilisateur n'a jamais créé de compte sur Keycloak ACRA. Son identité IREX a été reconnue et propagée à travers la chaîne de fédération. C'est le principe fondamental d'une fédération d'identité OIDC.

5.3 Tokens et propagation des attributs

En OIDC, l'identité de l'utilisateur est transportée dans un ID token au format JWT (JSON Web Token). Ce token est signé par l'IdP émetteur, ce qui permet à tout système qui lui fait confiance de vérifier son authenticité sans contacter l'IdP à chaque requête.

Ce token contient des claims : des informations sur l'utilisateur (identifiant, email, groupes, rôles…). Dans une fédération, l'IdP broker peut extraire certains de ces claims et les retransmettre — éventuellement transformés — vers l'application cible. C'est ce qui permet, par exemple, qu'un utilisateur ayant un rôle défini dans l'annuaire IREX se voie automatiquement attribuer les droits correspondants dans Grafana.

6. Avantages et défis

a) Avantages

b) Défis

7. Conclusion

La fédération d'identité apporte une réponse claire à un problème concret : comment permettre à des utilisateurs d'un domaine d'accéder aux ressources d'un autre, sans multiplier les comptes ni fragmenter la gestion des accès.

Son principe repose sur une relation de confiance entre deux IdP distincts. Dans le projet ACRA, cette relation est établie entre Keycloak ACRA et Keycloak IREX via OIDC : un membre de l'IREX accède à la plateforme de supervision en étant authentifié par son propre IdP, de façon transparente.

Si cet article en a posé les bases conceptuelles, la mise en œuvre concrète — configuration du broker Keycloak, création du client OIDC, gestion des mappers de rôles — fait l'objet de l'article suivant.

8. Voir aussi

• Configurer une fédération d’identité OIDC avec Keycloak
• OAuth2-Proxy : le gardien silencieux de vos applications sans authentification