SSO avec SAML 2.0 dans les Services Financiers : Implémentation Enterprise

Le secteur financier souffre d'un problème d'identité structurel : des dizaines de portails, de plateformes internes, d'applications de partenaires commerciaux et de services cloud, chacun avec son propre système d'authentification. La prolifération des identifiants favorise leur réutilisation et des parcours de récupération faibles ; le SSO réduit cette surface, mais n'élimine pas à lui seul l'hameçonnage ni le détournement de session : il s'accompagne de l'authentification multifacteur (MFA) et de contrôles de session.

SAML 2.0 et OpenID Connect : quand privilégier chacun

OAuth 2.0 délègue l'autorisation ; OpenID Connect ajoute l'authentification. SAML 2.0 et OIDC sont tous deux d'actualité : SAML reste fréquent dans les suites d'entreprise et la fédération B2B existante ; OIDC est généralement préférable pour les applications web et mobiles modernes et pour les API. SAML 2.0 a été conçu pour la fédération d'identité entre organisations, avec des assertions XML signées par des certificats X.509 et des attributs d'utilisateur complexes, et conserve une présence significative dans les environnements d'entreprise ; le choix dépend de la compatibilité, du modèle d'intégration, du modèle de menaces et de l'exploitation.

Dans les systèmes centraux métier et les plateformes héritées, la fédération exige généralement un portail, une passerelle ou une couche intermédiaire ; on valide, par produit et par version, le flux pris en charge, la session et les attributs disponibles. L'un comme l'autre peuvent nécessiter des composants d'intégration ; l'impact se mesure sur l'architecture concrète.

Architecture d'une mise en œuvre réelle

Sur le portail de bons d'Intelyvale, ses clients entreprises se connectent avec le compte de leur propre société : nous fédérons leur fournisseur d'identité et séparons cet accès de la connexion locale.

Les problèmes dont personne ne parle

La mise en œuvre technique de SAML est relativement directe avec des bibliothèques éprouvées. Les vrais problèmes apparaissent en exploitation réelle : rotation des certificats (si l'IdP renouvelle son certificat sans prévenir les SP, les utilisateurs sont bloqués ; avec les métadonnées, la rotation s'automatise), attributs incohérents (différents SP attendent le même attribut sous des noms différents), correspondance des rôles de l'annuaire du client avec ceux du système, création des utilisateurs au premier accès et déconnexion dans les écosystèmes hybrides.

Les assertions dépendent de conditions de temps (NotBefore / NotOnOrAfter) ; la tolérance est définie explicitement, aussi réduite que l'exploitation le permet, avec une synchronisation d'horloge surveillée.

Le fournisseur de service valide strictement la signature et la chaîne de confiance, l'émetteur, l'audience, la destination, la validité, la correspondance avec la requête et l'usage unique de l'assertion, et se protège contre le rejeu et le XML signature wrapping. Accepter une assertion « signée » ne suffit pas.