SAML et fédération

SAML (langage de balisage des assertions de sécurité) est une norme fondée sur XML pour l’échange de données d’authentification et d’autorisation, dominante dans le SSO d’entreprise.

• Elle permet à un fournisseur d’identité d’entreprise d’attester l’identité d’un utilisateur auprès de nombreuses applications.
• SAML 2.0 est antérieur à OIDC et reste profondément implanté dans les identités B2B et professionnelles.

Comprendre SAML est essentiel pour sécuriser la fédération d’entreprise, où une seule faille de confiance peut exposer toutes les applications connectées.

La fédération SAML repose sur deux parties principales.

• Le fournisseur d’identité (IdP) authentifie l’utilisateur et émet des assertions (Okta, Entra ID, Ping).
• Le fournisseur de services (SP) est l’application qui fait confiance à l’IdP et accorde l’accès.

La confiance est établie hors bande par échange de métadonnées, notamment les certificats de signature et les URL des points de terminaison.

L’élément central est l’assertion, un document XML indiquant que l’IdP a authentifié un sujet.

• Le sujet identifie l’utilisateur (NameID).
• Les conditions définissent la période de validité et l’audience prévue.
• AuthnStatement consigne comment et quand l’authentification a eu lieu.
• AttributeStatement contient les rôles, l’adresse e-mail et les revendications de groupe.

Le schéma le plus courant est le SSO initié par le SP.

• L’utilisateur accède au SP, qui génère une AuthnRequest et redirige l’utilisateur vers l’IdP.
• L’IdP authentifie l’utilisateur et envoie par POST une Response signée au service consommateur d’assertions (ACS) du SP.
• Le SP valide l’assertion et crée une session locale.

La sécurité de SAML repose sur les signatures numériques XML. L’IdP signe l’assertion (et/ou la réponse) avec sa clé privée ; le SP vérifie la signature avec le certificat de confiance.

• Signez l’assertion elle-même, et pas seulement la réponse englobante.
• Vérifiez la signature avec un certificat d’IdP épinglé provenant des métadonnées, et non avec un certificat intégré au message.

La plupart des attaques SAML ciblent la logique de validation des signatures.

L’enveloppement de signature XML est la catégorie d’attaque par signature propre à SAML. L’attaquant conserve un élément correctement signé, mais ajoute une seconde assertion falsifiée que la logique de l’application lit effectivement.

• La signature reste valide pour le fragment original.
• Mais la logique métier traite l’assertion injectée et non signée.

Mesures d’atténuation : utilisez une bibliothèque SAML renforcée, vérifiez que l’élément signé est bien celui qui est traité et rejetez les documents comportant plusieurs assertions ou des assertions ambiguës.

Une assertion doit être liée au SP prévu. SAML fournit des restrictions explicites.

• AudienceRestriction désigne l’ID d’entité du SP pour lequel l’assertion est valide.
• Le destinataire dans SubjectConfirmation doit correspondre à l’URL de l’ACS.

Le SP doit faire respecter ces restrictions. Omettre la vérification de l’audience permet de rejouer auprès d’une autre application une assertion émise pour une première application.

Les assertions sont des identifiants à courte durée de vie et à usage unique. Les SP doivent faire respecter cette règle.

• Respectez NotBefore et NotOnOrAfter avec une dérive d’horloge très faible.
• Suivez l’ID de l’assertion et rejetez toute réutilisation pendant la période de validité.
• Exigez TLS sur le point de terminaison de l’ACS.

Sans suivi des rejeux, une assertion interceptée peut être soumise à nouveau avant son expiration.

La fédération étend le SSO au-delà des frontières organisationnelles, parfois au moyen de concentrateurs ou de courtiers qui assurent la traduction entre les protocoles.

• Chaque lien de confiance constitue un point faible potentiel ; un IdP compromis peut usurper l'identité de chaque utilisateur.
• Les courtiers d'identité peuvent faire le lien entre SAML et OIDC, ce qui exige une correspondance rigoureuse des revendications.

Appliquez le principe du moindre privilège au mappage des attributs et surveillez l'apparition inattendue de nouveaux enregistrements de SP.

Voici des modes de défaillance SAML récurrents qu'il convient d'auditer :

• La signature n'est pas vérifiée, ou la réponse est signée mais pas l'assertion.
• Le système est vulnérable à l'attaque par enveloppement de signature XML.
• Les vérifications de l'audience et du destinataire sont absentes.
• Aucune protection contre la relecture, ou des périodes de validité excessivement longues.
• Analyse des entités externes XML (XXE) sur le SP.
• Le certificat intégré au message est considéré comme fiable au lieu d'utiliser des métadonnées épinglées.

Les deux fournissent le SSO, mais leur conception diffère.

• SAML XML, liaisons POST/redirection du navigateur, très répandu dans les environnements d'entreprise et professionnels, outils éprouvés.
• OIDC JSON/JWT, adapté à REST, mieux adapté aux appareils mobiles et aux applications monopages.

De nombreuses organisations utilisent les deux. Les défenseurs doivent connaître les règles de validation des assertions du protocole utilisé par chaque application, car la surface d'attaque diffère.

Points essentiels :

• SAML est un SSO d'entreprise fondé sur XML, entre un IdP et un SP, au moyen d'assertions signées.
• La sécurité dépend de la validation correcte de la signature XML par rapport à un certificat épinglé.
• Protégez-vous contre l'enveloppement de signature XML, la relecture et les attaques XXE.
• Appliquez toujours les restrictions d'audience et de destinataire ainsi que les périodes de validité.
• La fédération étend la confiance, mais amplifie le rayon d'impact d'un IdP compromis.