Fédérer un Identity Provider depuis un IAM

Dans l’écosystème numérique interconnecté d’aujourd’hui, les solutions d’Identity and Access Management (IAM) ont souvent besoin de déléguer l’authentification à des Identity Providers (IdP) externes. Ce mécanisme, appelé fédération d’un Identity Provider, permet une intégration fluide entre plateformes, organisations, et même services destinés aux clients.

Nous allons explorer deux cas de fédération distincts, en considérant à la fois l’IAM interne et le CIAM. Chaque scénario a ses propres motivations et contraintes techniques, qui influencent sa mise en œuvre.

Cas d’usage : fédération d’un IAM interne

Une organisation utilise une solution IAM interne pour authentifier ses utilisateurs, mais doit fédérer l’authentification vers un autre IdP de confiance. C’est fréquent lors de collaborations avec des organisations partenaires ou de l’intégration à des solutions d’identité à l’échelle de l’entreprise.

Voici quelques cas d’usage courants de la fédération d’un IAM interne :

• Collaboration inter-entreprises : fédération avec l’IdP d’une entreprise partenaire pour accéder de manière sécurisée à des ressources partagées.
• Gouvernance centralisée des identités : un grand groupe consolide l’authentification de plusieurs unités métier, qui utilisent des systèmes IAM différents, sous un IdP d’entreprise unique.

Points d’attention

Lors de la fédération d’un IdP depuis un IAM interne, plusieurs facteurs sont à prendre en compte pour garantir une intégration fluide et sécurisée :

• Relation de confiance (Trust Relationship) : mettre en place un mécanisme de confiance entre l’IAM interne et l’IdP externe. Cela passe souvent par la signature d’accords OIDC, l’échange de métadonnées et l’usage de couches de transport sécurisées.
• Alignement des protocoles : s’assurer que l’IAM interne et l’IdP externe supportent les mêmes spécifications et fonctionnalités OIDC, comme le mapping des claims, la durée de vie des jetons et les scopes.
• Synchronisation des utilisateurs : décider si les attributs des utilisateurs sont synchronisés en temps réel ou récupérés dynamiquement via les claims de l’IdP fédéré. Sécurité, notamment en veillant au respect strict des politiques d’accès.

Cas d’usage : fédération d’un IAM grand public (CIAM)

Une entreprise proposant des services à ses clients utilise son propre IAM, mais souhaite simplifier la connexion en laissant les utilisateurs s’authentifier avec l’IdP externe de leur choix, comme les connexions sociales (Google, Facebook, Apple) ou des IdP étatiques comme FranceConnect en France.

Voici quelques cas d’usage courants de la fédération CIAM :

• Connexion sociale pour plus de confort : permettre aux clients de se connecter avec des comptes qu’ils possèdent déjà (par exemple Google, Facebook).
• Identités étatiques ou fédérées : permettre la connexion via des IdP adossés à l’État pour les services nécessitant une vérification d’identité légale, comme la santé ou les services d’administration en ligne.

Points d’attention

Lors de la fédération d’un IdP depuis un IAM, plusieurs facteurs sont à prendre en compte pour garantir une intégration fluide et sécurisée :

• Onboarding des utilisateurs : garantir un parcours d’inscription fluide en mappant les attributs de l’utilisateur de l’IdP externe vers l’IAM client.
• Image de marque et confiance : conserver une expérience cohérente avec votre marque tout en intégrant une authentification tierce.
• Vie privée : trouver l’équilibre entre facilité d’usage et respect de la vie privée des clients, en veillant à ne partager et stocker que les données essentielles.

Protocoles de fédération : OIDC, SAML et au-delà

Lors de la mise en place d’une fédération entre des IAM et des IdP externes, le choix du bon protocole standard est déterminant pour la compatibilité, la sécurité et les performances. Les deux protocoles de fédération les plus utilisés sont OpenID Connect (OIDC) et Security Assertion Markup Language (SAML 2.0). Tous deux offrent un cadre solide pour l’identité fédérée, mais diffèrent par leur approche, leurs cas d’usage et leurs fondations techniques.

Interopérabilité entre protocoles

Dans certains cas, les organisations doivent faire le pont entre OIDC et SAML. Par exemple, un IAM interne supportant SAML peut devoir se fédérer avec un IdP moderne utilisant OIDC. Des solutions de middleware et des identity brokers (par exemple Okta, Keycloak, PingFederate ou Azure AD) peuvent assurer la traduction entre protocoles, afin que les systèmes communiquent sans encombre malgré leurs différences.

Mettre en œuvre la fédération avec OpenID Connect

Fédérer une solution IAM avec un Identity Provider (IdP) externe via OpenID Connect (OIDC) consiste à intégrer votre IAM au flow OIDC pour déléguer l’authentification et obtenir les informations de l’utilisateur en toute sécurité. Cette section présente les étapes et les best practices pour mettre en œuvre la fédération OIDC.

Vue d’ensemble du flow OIDC

Avant l’implémentation, il est essentiel de comprendre le fonctionnement du protocole OIDC dans ce contexte. La fédération utilise généralement l’Authorization Code Flow (avec l’extension PKCE), qui sécurise les échanges entre votre IAM (agissant comme client) et l’IdP externe. Le flow se déroule selon les étapes suivantes :

1. Requête d'autorisation

   L’IAM redirige l’utilisateur vers l’authorization endpoint de l’IdP externe, en transmettant des paramètres comme le client ID, la redirect URI et les scopes demandés.

2. Réponse d'autorisation

   L’IdP authentifie l’utilisateur et le redirige vers la redirect URI de l’IAM avec un authorization code.

3. Échange de jetons

   L’IAM échange l’authorization code contre des jetons (ID token, access token) en appelant le token endpoint de l’IdP.

4. Récupération des informations utilisateur

   L’IAM utilise l’ID token lorsqu’il existe, ou l’access token pour appeler le userinfo endpoint de l’IdP afin d’obtenir des claims utilisateur supplémentaires.

5. Établissement de la session

   L’IAM établit une session et donne accès à l’application.

Flow de première connexion

Lors de la première connexion, l’utilisateur est redirigé vers l’IdP externe pour s’authentifier. L’IdP peut lui demander son consentement pour le partage d’informations, puisqu’il s’agit de sa première connexion.

Après une authentification réussie, l’IAM reçoit un access token et, la plupart du temps, un ID token. S’agissant d’une première connexion, l’IAM peut créer un nouveau compte utilisateur. Il stocke au minimum l’identifiant de l’utilisateur (sub) afin de lier l’utilisateur externe à l’utilisateur interne lors des connexions suivantes.

Flow des connexions suivantes

Pour les connexions suivantes, le flow est identique, sauf que l’utilisateur n’a plus à donner son consentement, puisqu’il l’a déjà fait lors de la première connexion. Dans certains cas, par exemple si les scopes changent, le consentement peut lui être redemandé. Lorsque l’IAM reçoit l’access token et l’ID token, il utilise l’identifiant de l’utilisateur (sub) pour lier l’utilisateur externe à l’utilisateur interne.

Pour garder les données à jour, l’IAM peut continuer à mapper les claims de l’utilisateur de l’IdP externe vers le compte utilisateur interne à chaque connexion.

Et le Account Linking ?

Le account linking (liaison de comptes) consiste à associer un compte utilisateur externe (provenant de l’IdP) à un compte utilisateur interne de l’IAM à partir d’attributs de l’utilisateur (par exemple l’e-mail ou le numéro de téléphone). Cela permet de conserver une expérience utilisateur cohérente et de garantir l’intégrité des données entre les systèmes. Si vous avez déjà un compte avec la même adresse e-mail, mais que vous ne vous en souvenez plus et souhaitez cette fois vous connecter avec Google par exemple, le account linking évite la création d’un nouveau compte.

Cependant, le account linking ajoute des défis de sécurité, comme s’assurer que l’utilisateur est bien le propriétaire légitime des deux comptes et prévenir la prise de contrôle de compte (account takeover). Vous devez faire confiance à l’IdP externe pour fournir des informations utilisateur exactes et sûres, afin d’éviter des risques de sécurité. Si, par exemple, l’adresse e-mail n’est pas vérifiée par l’IdP, cela représente un risque.

Configurer votre IAM comme client OIDC

Dans votre IAM, configurez une connexion vers l’IdP externe en agissant comme un client OIDC. La configuration comprend :

• Enregistrer l’IdP : ajoutez l’endpoint de configuration OpenID Connect ou la configuration manuelle, incluant les endpoints, le client ID et le client secret.
• Définir les scopes : indiquez les scopes dont vous avez besoin, comme openid, profile, email, ou des scopes personnalisés fournis par l’IdP.
• Mapping des claims : mappez les claims (attributs de l’utilisateur) fournis par l’IdP externe vers votre schéma utilisateur interne.
• Validation des jetons : mettez en place la validation de la signature des jetons pour vous assurer que ceux reçus de l’IdP sont authentiques et sûrs avant de les traiter.

Exemple de cas d’usage

Imaginons une entreprise utilisant Keycloak comme IAM interne, qui se fédère avec le provider OIDC de Google pour proposer la connexion Google dans ses applications. L’intégration implique :

• Enregistrer Keycloak comme client OIDC dans la Google Cloud Console.
• Configurer Google comme IdP dans Keycloak à l’aide de l’URL de métadonnées de Google et des credentials du client.
• Mapper les claims email et name de Google vers les attributs utilisateur de Keycloak.
• Tester le flow en se connectant à une application et en vérifiant que la session est bien établie dans Keycloak.

Attention : points de vigilance sur le mapping en fédération

Lors de la fédération avec des providers OIDC externes, il est important de garder à l’esprit que chaque provider peut gérer différemment les claims, les scopes et les attributs des utilisateurs. Ces variations peuvent avoir un impact important sur l’intégration et demandent une attention particulière lors de l’implémentation.

Voici quelques spécificités courantes chez certains providers :

• Paramètres d’autorisation personnalisés (acr_values) : certains providers exigent des paramètres supplémentaires, comme acr_values, dans la requête d’autorisation pour imposer des politiques d’authentification spécifiques. Par exemple, les IdP étatiques peuvent exiger acr_values pour indiquer le niveau d’assurance (LoA) souhaité pour l’authentification.
• Attributs disponibles une seule fois : certains providers, comme Apple, ne renvoient certains attributs d’identité que lors de la première connexion pour un client donné. Des attributs comme le nom peuvent être fournis lors de l’authentification initiale, mais ne sont plus disponibles lors des connexions suivantes.