Une application et son identity provider ne sont pas obligés de prendre en charge le même protocole de fédération. Une application moderne peut utiliser OpenID Connect alors qu’un identity provider d’entreprise ou de partenaire établi utilise encore SAML 2.0. Réécrire l’un des côtés uniquement pour aligner les protocoles peut ajouter des coûts, des risques de migration et des dépendances inutiles.

Un bridge SAML vers OpenID Connect permet à chaque côté de conserver le protocole qu’il prend déjà en charge. FoxIDs valide la réponse SAML 2.0 de l’identity provider externe, applique les claims et les règles de sécurité nécessaires, puis émet la réponse OpenID Connect attendue par l’application.

Les recherches sur ce problème utilisent souvent des expressions techniques courtes comme SAML vers OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, traduction de protocole, traduction SAML vers OIDC, token translation, identity broker ou identity federation broker. La question d’architecture reste la même : comment une application peut-elle faire confiance à un contrat OpenID Connect moderne tandis qu’un identity provider existant, un partenaire ou une ancienne application SAML continue d’utiliser le protocole déjà pris en charge ?

Il ne s’agit pas simplement de convertir un format de token. Un bridge utile doit préserver l’identité voulue, l’authentication assurance et le contrat de l’application entre deux standards dont les formats de message, les modèles de signature, les sessions et les conventions de claims diffèrent.

Quand utiliser le protocol bridging

Le protocol bridging est pertinent lorsqu’il crée une frontière contrôlée entre des systèmes qui doivent évoluer à des rythmes différents.

Situations courantes :

  • Une nouvelle application web, mobile ou single-page prend en charge OpenID Connect, mais les clients ou partenaires s’authentifient auprès d’identity providers SAML 2.0.
  • Des applications SAML 2.0 existantes doivent utiliser un identity provider OpenID Connect moderne.
  • Une organisation remplace progressivement AD FS ou une autre plateforme de fédération, par exemple dans une migration AD FS vers OpenID Connect, au lieu de modifier toutes les applications en même temps.
  • Plusieurs applications doivent faire confiance à une seule couche d’identité, même si les identity providers externes utilisent des protocoles différents.
  • Une migration nécessite des environnements de test et de production parallèles avec une voie de rollback claire.

Si les deux côtés prennent déjà en charge le même protocole adapté et peuvent être connectés en toute sécurité, un bridge n’apporte pas nécessairement de valeur. Utilisez-le pour réduire le couplage ou permettre une évolution progressive, pas uniquement parce qu’une traduction de protocole est possible.

Décidez tôt si le bridge constitue une étape de migration ou un composant d’architecture durable. Un bridge temporaire nécessite des critères de sortie explicites pour supprimer l’ancienne relation de trust. Un bridge durable nécessite une responsabilité d’exploitation clairement attribuée, une supervision et une gestion du cycle de vie des certificats des deux côtés.

Choisir d’abord le contrat côté application

Le protocole exposé à l’application doit normalement correspondre à son architecture et à son orientation à long terme. Les nouvelles applications utilisent souvent OpenID Connect pour la connexion et OAuth 2.0 pour l’accès aux API. Des applications d’entreprise existantes peuvent devoir rester en SAML 2.0 jusqu’à leur remplacement.

Dans FoxIDs, l’application est enregistrée avec le protocole qu’elle consomme. L’identity provider externe est configuré comme authentication method avec le protocole qu’il propose. FoxIDs se trouve à la frontière de trust :

SAML 2.0 identity provider → FoxIDs → application OpenID Connect

Le sens inverse est également possible :

OpenID Connect identity provider → FoxIDs → application SAML 2.0

Cette séparation permet aux équipes applicatives de standardiser un contrat sans exiger que tous les identity providers externes changent simultanément.

Deux parcours de protocol bridging via FoxIDs : SAML 2.0 vers OpenID Connect et OpenID Connect vers SAML 2.0.
FoxIDs permet à l’application et au fournisseur d’identité d’utiliser les protocoles qu’ils prennent en charge, avec FoxIDs comme frontière de confiance commune.

Préserver la sémantique de l’identité, pas seulement les noms de claims

Les SAML assertions et les OpenID Connect tokens représentent l’identité différemment. Un mapping direct des noms suffit rarement en production.

Définissez explicitement le contrat de l’application :

  • Quel identifiant reste stable pour une même personne entre les sessions et les identity providers ?
  • Quels claims sont nécessaires à l’affichage, à l’autorisation et à l’audit ?
  • Comment les groupes et rôles sont-ils représentés, filtrés et transformés ?
  • À quels issuer et audience l’application fait-elle confiance ?
  • Que se passe-t-il si un provider externe omet un claim obligatoire ?
  • Les identités de plusieurs providers peuvent-elles être corrélées en sécurité ou doivent-elles rester distinctes ?

FoxIDs utilise des JWT claims en interne et peut mapper les types de claims SAML vers les noms plus courts courants dans OpenID Connect. Ce claim mapping peut aussi transformer des valeurs avant qu’elles n’atteignent l’application. Limitez volontairement le mapping : émettez les claims nécessaires au lieu de copier chaque attribut externe dans chaque token.

Les identifiants stables demandent une attention particulière. Les adresses e-mail et noms d’utilisateur peuvent changer et constituent généralement de mauvaises clés primaires. Préférez un identifiant source immuable associé à un issuer clairement défini, ou un autre identifiant au cycle de vie contrôlé.

Identifiants, claims et contexte d’authentification SAML 2.0 mappés via FoxIDs vers des tokens OpenID Connect.
Le bridge mappe les identifiants stables, les claims nécessaires et les signaux d’assurance au lieu de copier chaque attribut du fournisseur d’identité externe.

Suivre une identité à travers le bridge

Prenons un utilisateur partenaire qui se connecte via un SAML 2.0 identity provider alors que l’application utilise OpenID Connect :

  • La SAML assertion fournit un NameID immuable, une adresse e-mail, l’appartenance aux groupes et un authentication context.
  • FoxIDs valide la signature, l’issuer, l’audience et la durée de validité, puis mappe l’identifiant source stable vers sub, les groupes sélectionnés vers les rôles de l’application et l’authentication context accepté vers acr.
  • L’application reçoit uniquement les OpenID Connect claims convenus et valide FoxIDs comme issuer.

L’application n’a pas besoin de logique SAML propre à chaque partenaire. Lorsqu’un autre partenaire identity provider est ajouté, ses claims et signaux d’assurance sont normalisés à la frontière FoxIDs sans modifier le contrat de token de l’application.

Gérer consciemment l’authentication assurance

Une connexion SAML réussie n’indique pas automatiquement à une application OpenID Connect si une MFA a été utilisée ni quelles exigences d’assurance ont été satisfaites.

Définissez la relation entre le SAML authentication context, l’OpenID Connect authentication context et les valeurs acr attendues. Décidez si FoxIDs peut accepter l’assurance externe, doit demander à l’identity provider externe un authentication step plus fort ou doit refuser la connexion lorsque le context requis manque.

Le même principe s’applique dans l’autre sens. Une application SAML 2.0 peut attendre un authentication context particulier lorsque l’utilisateur se connecte via un OpenID Connect identity provider.

Ne déduisez pas une authentication forte de la seule présence d’une session chez l’identity provider externe. Évaluez l’authentication context retourné selon les règles d’assurance configurées et testez les parcours acceptés comme les refus.

Distinguer les sessions de connexion des informations de déconnexion

OpenID Connect et SAML 2.0 utilisent des mécanismes de session et de déconnexion différents. L’identity provider externe et l’application gèrent chacun leur propre session de connexion. FoxIDs ne maintient pas une troisième session de connexion utilisateur entre eux ; il conserve uniquement les informations de session nécessaires pour coordonner la déconnexion.

Lors de la connexion, de la reauthentication et du step-up, FoxIDs envoie une authentication request à l’identity provider externe. FoxIDs ne réutilise pas les informations de déconnexion comme session de connexion. L’identity provider externe décide, selon sa propre session et les exigences de la request, si l’utilisateur peut poursuivre sans interaction ou doit s’authentifier à nouveau.

FoxIDs peut utiliser les informations de déconnexion conservées pour coordonner la déconnexion entre les relations concernées. Le single logout de bout en bout peut fonctionner si tous les participants prennent en charge des flux compatibles et si le navigateur peut joindre chaque endpoint, mais il ne faut pas le supposer. Testez les front-channel redirects, les sessions externes expirées, la déconnexion partielle, plusieurs applications et la déconnexion initiée par le provider.

Alignez les durées de l’application et des tokens sur le comportement attendu de la session de l’identity provider externe. La fin de la session applicative ne termine pas nécessairement la session externe. Les exigences de reauthentication et de step-up doivent être transmises dans une nouvelle request et vérifiées à partir de l’authentication context retourné.

Planifier une migration SAML vers OpenID Connect progressive

Une migration contrôlée garde visibles le bridge, le contrat applicatif et la voie de rollback.

  1. Inventorier les relations actuelles. Recensez applications, identity providers, métadonnées, certificats, endpoints, claims, identifiants, exigences MFA, comportement des sessions et responsables.
  2. Définir le contrat cible. Décidez quelles applications utiliseront OpenID Connect, quelles relations SAML 2.0 resteront et quels claims et signaux d’assurance traverseront le bridge.
  3. Configurer les deux relations de trust. Ajoutez le provider externe comme FoxIDs authentication method et l’application comme FoxIDs application registration.
  4. Tester aussi les échecs. Incluez signatures invalides, mauvais issuer ou audience, claims absents, assertions expirées, protection contre le replay, écarts d’horloge, déconnexion et rotation des certificats.
  5. Utiliser un environnement séparé. Validez l’intégration sans modifier le trafic de production, puis faites progresser la configuration contrôlée dans les environnements.
  6. Déplacer d’abord un périmètre limité. Utilisez une application pilote, un partenaire ou un groupe d’utilisateurs et conservez l’ancien chemin jusqu’à validation du nouveau.
  7. Observer et achever le cut-over. Surveillez erreurs d’authentication, différences de claims et demandes de support avant de supprimer l’ancienne relation de trust.

Les FoxIDs tenants peuvent contenir des environnements distincts de développement, test, migration et production. Cela facilite la validation parallèle et un cut-over progressif, sans remplacer un plan de rollback ni les tests applicatifs.

Migration en sept étapes, de l’inventaire et du contrat cible à la configuration de trust, aux tests, aux environnements contrôlés, au pilote et au cut-over en production, avec rollback.
Une migration progressive valide les relations de confiance et le comportement de l’application avant la bascule en production, tout en conservant le rollback jusqu’à ce que le nouveau parcours soit éprouvé.

Exiger des preuves de production avant le cut-over

Le bridge fait partie du chemin d’authentication et doit être exploité comme une frontière de sécurité. Convenez des preuves requises pour chaque décision de production au lieu de considérer une connexion réussie comme une acceptation.

Domaine de décision Preuves requises avant la production
Trust endpoints Responsables désignés, métadonnées vérifiées et restrictions d’issuer, audience, recipient et redirect URI
Credentials Clés contrôlées distinctes, algorithmes acceptés, test de rotation des certificats et responsable du renouvellement
Contrat d’identité Subject stable, liste de claims autorisés, transformations documentées et comportement défini lorsque des claims obligatoires manquent
Authentication assurance Contexts externes acceptés, règles de MFA supplémentaire et parcours de refus testés
Connexion et déconnexion Transmission testée des requests de connexion, reauthentication et step-up, ainsi que déconnexion, déconnexion partielle et durées pertinentes des tokens et sessions externes
Échecs et exploitation Tests des messages invalides, expirés et rejoués, ainsi que journaux d’audit, alertes, responsabilité du support et décision de rollback

Évitez de copier des clés privées entre systèmes uniquement pour simplifier la migration. Donnez à chaque relation de trust ses propres credentials contrôlés et planifiez leur rotation avant l’expiration des certificats.

Comment FoxIDs prend en charge le bridge

FoxIDs met en œuvre le protocol bridging avec son modèle habituel d’applications et d’authentication methods. Aucun bridge service distinct n’est à déployer. Une application OpenID Connect peut utiliser des authentication methods SAML 2.0, OpenID Connect ou WS-Federation, et une application SAML 2.0 peut utiliser les mêmes sources externes.

Les équipes applicatives disposent ainsi d’un contrat FoxIDs identity provider unique, tandis que les identity providers, partenaires et systèmes anciens se connectent avec les standards qu’ils prennent en charge. FoxIDs fournit aussi le claim mapping, des authentication flows configurables, la MFA et des environnements séparés de test et de production.

Consultez la documentation du protocol bridge pour le modèle de configuration exact, les authentication methods et les application registrations. Si le projet comprend l’onboarding d’applications, la conception des claims, les tests ou une migration progressive, FoxIDs Identity Integration présente l’aide à l’implémentation proposée par l’équipe qui développe la plateforme.

Conclusion

Un bridge SAML vers OpenID Connect est particulièrement utile lorsqu’il permet aux applications et aux identity providers d’évoluer indépendamment sans affaiblir le contrat d’identité.

Traitez le bridge comme une frontière de trust délibérée, et non comme un traducteur de tokens invisible. Lorsque le contrat de l’application, les règles d’assurance, le comportement de connexion et de déconnexion, les preuves de production, les responsabilités et le rollback sont explicites, FoxIDs fournit le modèle d’implémentation fondé sur les standards pour introduire le changement par étapes contrôlées.