Bridge SAML 2.0, OpenID Connect et WS-Federation

FoxIDs peut agir comme bridge de protocoles entre SAML 2.0, OpenID Connect / OAuth 2.0 et WS-Federation. Cela permet à une application de continuer à utiliser un protocole d’identité tandis que l’identity provider externe ou l’application partenaire en utilise un autre.

Le bridge n’est pas un composant séparé à installer. C’est le modèle normal de FoxIDs : les utilisateurs se connectent via une méthode d’authentification, et FoxIDs émet la réponse requise par l’application registration. Lorsque les deux côtés utilisent des standards différents, FoxIDs assure la traduction de protocole, le claim mapping, la création de tokens et le routage de connexion.

Certaines équipes décrivent cela comme protocol translation, traduction SAML vers OIDC, token translation, identity broker ou federation broker. Dans FoxIDs, ces termes décrivent le même modèle de configuration, mais la conception doit toujours être revue comme une frontière d’identity trust. Le résultat important n’est pas seulement la traduction de messages ou de tokens, mais un contrat applicatif, un issuer, une audience, des claims et un comportement de déconnexion cohérents entre les standards connectés.

Utilisez le bridge lorsque :

Une application prend déjà en charge OpenID Connect et doit connecter des utilisateurs depuis un identity provider SAML 2.0 ou WS-Federation.
Une application SAML 2.0 ou WS-Federation doit utiliser un identity provider OpenID Connect.
Une application legacy WS-Federation ou SAML 2.0 doit être connectée à une plateforme d’identité OpenID Connect moderne sans modifier l’application.
Plusieurs applications doivent faire confiance au même environnement FoxIDs même si elles utilisent des standards différents.

Federated Identity Management (FIM) relie les identités entre domaines. Single Sign-On (SSO) permet aux utilisateurs d’accéder aux applications sans se reconnecter. FoxIDs prend en charge les deux, et le bridge permet à FIM et SSO de fonctionner au-delà des frontières de protocoles.

Fonctionnement du bridge

OpenID Connect, SAML 2.0 et WS-Federation résolvent beaucoup des mêmes besoins d’identité, mais leurs messages, tokens, métadonnées, certificats et formats de claims sont différents.

OpenID Connect repose sur OAuth 2.0 et est couramment utilisé par les applications web, mobiles et basées sur des API modernes. Il utilise des JSON Web Tokens (JWT) comme identity tokens et access tokens.
SAML 2.0 est basé sur XML et largement utilisé pour le SSO enterprise basé sur navigateur. Il utilise des SAML assertions et des signatures XML.
WS-Federation est basé sur XML et couramment utilisé par les applications web enterprise et legacy. Il utilise généralement des tokens SAML 1.1 ou SAML 2.0 dans les réponses de connexion WS-Federation.

FoxIDs bridge ces standards en agissant comme partie de confiance des deux côtés de la connexion :

Vers l’identity provider externe, FoxIDs est configuré comme méthode d’authentification.
Vers l’application, FoxIDs est configuré comme application registration.
En interne, FoxIDs représente les claims comme des JWT claims et mappe entre JWT claims et SAML claims lorsque nécessaire.
L’application reçoit la réponse de protocole qu’elle comprend déjà.

Il n’est pas nécessaire que les protocoles entrant et sortant soient identiques. Une application OpenID Connect peut utiliser une méthode d’authentification SAML 2.0. Une application SAML 2.0 peut utiliser une méthode d’authentification OpenID Connect. WS-Federation peut également être utilisé de chaque côté.

Configurer un bridge

Un bridge est configuré en combinant une méthode d’authentification avec une application registration dans le même environnement.

Configurez l’identity provider upstream comme méthode d’authentification :
- Méthode d’authentification OpenID Connect
- Méthode d’authentification SAML 2.0
- Méthode d’authentification WS-Federation
Configurez l’application comme application registration :
- OpenID Connect application registration
- SAML 2.0 application registration
- WS-Federation application registration
Dans l’application registration, sélectionnez la méthode d’authentification qui doit gérer la connexion.
Si plusieurs méthodes d’authentification sont disponibles, l’application peut en sélectionner une directement, ou l’utilisateur peut choisir sur une page home realm discovery (HRD).
Vérifiez les claim mappings, certificats, métadonnées et le comportement de logout pour les standards utilisés de chaque côté.

Le choix de configuration le plus important n’est donc pas un paramètre bridge spécial. C’est l’association entre méthode d’authentification et application registration.

SAML 2.0 vers OpenID Connect

Ce bridge est fréquent lorsqu’une application prend déjà en charge OpenID Connect, mais que l’organisation ou l’identity provider partenaire ne prend en charge que SAML 2.0.

Configurez l’IdP externe comme méthode d’authentification SAML 2.0. Configurez l’application comme OpenID Connect application registration et sélectionnez la méthode d’authentification SAML 2.0.

Lorsque l’application envoie une demande de connexion OpenID Connect, FoxIDs route l’utilisateur vers l’IdP SAML 2.0 externe. La réponse SAML 2.0 est validée, les SAML 2.0 claims sont mappés vers des JWT claims, et FoxIDs renvoie une réponse OpenID Connect à l’application.

Bridge SAML 2.0 vers OpenID Connect

Consultez Bridge SAML vers OIDC pour applications OpenID Connect pour obtenir des conseils sur l’architecture, la conception des claims, la migration et la préparation à la production.

OpenID Connect vers SAML 2.0

Ce bridge est utile lorsqu’une application SAML 2.0 doit utiliser un identity provider OpenID Connect moderne.

Configurez le provider externe comme méthode d’authentification OpenID Connect. Configurez l’application comme SAML 2.0 application registration et sélectionnez la méthode d’authentification OpenID Connect.

Lorsque l’application SAML 2.0 envoie une SAML 2.0 Authn Request, FoxIDs route l’utilisateur vers l’OpenID Provider (OP). La réponse OpenID Connect est validée, les JWT claims sont mappés vers des SAML 2.0 claims, et FoxIDs renvoie une réponse SAML 2.0 à l’application.

Bridge OpenID Connect vers SAML 2.0

FoxIDs prend en charge le bridging de sign-in, logout et single logout entre SAML 2.0 et OpenID Connect.

Scénarios de bridge WS-Federation

WS-Federation fonctionne selon le même modèle que les autres standards. Il peut être configuré comme méthode d’authentification lorsque l’identity provider externe est un WS-Federation Security Token Service (STS), et comme application registration lorsque l’application attend une réponse de connexion WS-Federation.

Les scénarios typiques de bridge WS-Federation incluent :

IdP WS-Federation vers application OpenID Connect.
IdP OpenID Connect vers application WS-Federation.
IdP WS-Federation vers application SAML 2.0.
IdP SAML 2.0 vers application WS-Federation.

C’est utile pour les scénarios de remplacement AD FS, les anciennes applications ASP.NET, SharePoint, Dynamics et d’autres systèmes qui utilisent encore WS-Federation, tandis que les nouvelles applications et API peuvent continuer à utiliser OpenID Connect et OAuth 2.0.

Un environnement, un Identity Provider

Toutes les fonctionnalités de bridge peuvent être combinées dans le même environnement FoxIDs. Par exemple, une application OpenID Connect peut prendre en charge la connexion via des méthodes d’authentification SAML 2.0 et OpenID Connect en même temps.

Il est souvent plus simple de laisser les applications et API faire confiance à un seul environnement FoxIDs comme leur Identity Provider (IdP), même si les utilisateurs s’authentifient via différents protocoles externes. Dans ce modèle :

Les applications sont enregistrées dans FoxIDs avec le protocole qu’elles prennent déjà en charge.
Les identity providers externes sont configurés comme méthodes d’authentification.
FoxIDs effectue la traduction de protocole et le claim mapping entre les deux côtés.
Les clients OpenID Connect et les API OAuth 2.0 peuvent continuer à utiliser des ID tokens et access tokens, même lorsque la connexion initiale vient de SAML 2.0 ou WS-Federation.

Ce modèle est particulièrement utile lorsqu’un paysage applicatif est modernisé progressivement. Les systèmes SAML 2.0 et WS-Federation existants peuvent continuer à fonctionner tandis que les nouvelles applications utilisent OpenID Connect et OAuth 2.0.

Token exchange

Si un utilisateur se connecte à une application SAML 2.0 via un IdP SAML 2.0 externe, l’application reçoit un token SAML 2.0 pour cet utilisateur. Dans les architectures zero trust, les API doivent toujours être appelées dans le contexte de l’utilisateur final.

Utilisez token exchange lorsqu’un token SAML 2.0 doit être échangé contre un access token OAuth 2.0. L’access token résultant peut être utilisé pour appeler des API compatibles OAuth 2.0 dans le contexte de l’utilisateur connecté.

Mappages des revendications

FoxIDs utilise en interne les revendications JWT et mappe les revendications SAML 2.0 vers les revendications JWT. Le même modèle de mappage des revendications SAML/JWT est également utilisé pour WS-Federation, car les jetons WS-Federation contiennent des revendications SAML.

Par défaut, des correspondances standard sont appliquées, par exemple sub vers http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier et email vers http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

Vous pouvez consulter et configurer les mappages de revendications dans l’onglet Paramètres > Mappages de revendications de l’environnement, décrit dans la section Paramètres de l’environnement. Si aucun mappage n’existe pour une revendication, FoxIDs conserve le nom d’origine de la revendication. Cela permet de préserver les revendications à travers le pont tout en autorisant l’utilisation de noms de revendications plus courts JWT lorsque des mappages sont configurés.

Mappages personnalisés

Les mappages personnalisés sont associés à l'environnement et établissent une correspondance entre un type de revendication JWT et un type de revendication SAML. Un mappage personnalisé a priorité sur une valeur par défaut modifiable pour le même type de revendication entrante, mais il ne peut pas remplacer un mappage par défaut verrouillé.

Lorsque l'option ** Créer automatiquement des mappages entre les types de claims JWT et SAML ** est activée dans les paramètres de l'environnement, FoxIDs peut ajouter des mappages personnalisés pour les types de claims non encore mappés au fur et à mesure de leur traitement. Vous pouvez également ajouter, modifier ou supprimer manuellement des mappages personnalisés.

Mappages par défaut

Les mappages de claims SAML 2.0 et JWT par défaut sont intégrés à FoxIDs et sont en lecture seule dans Control Client. Les mappages par défaut verrouillés sont toujours appliqués. Les mappages par défaut modifiables ne sont utilisés que lorsqu’aucun mappage personnalisé n’a la priorité pour le type de claim entrant.