SAML 2.0¶

Pourquoi SAML ?¶

SAML 2.0 est une norme XML largement utilisée pour le SSO entre organisations et applications d’entreprise. L’Identity Provider (IdP) authentifie l’utilisateur et produit une assertion ; le Service Provider (SP) consomme la réponse et ouvre une session applicative. Keycloak peut agir comme IdP SAML ou, selon le scénario, comme courtier vers un IdP externe.

SAML transporte des déclarations d’identité et d’authentification ; il ne décide pas à lui seul des autorisations métier. Le SP mappe les attributs reçus à ses propres comptes et permissions.

Assertion et messages¶

Une assertion est un document XML signé et parfois chiffré contenant notamment :

• un sujet et un NameID (identifiant du principal) ;
• des informations d’authentification (AuthnStatement) ;
• des attributs (AttributeStatement) ;
• des conditions telles que l’émetteur, les dates de validité, l’audience et les destinataires.

L’AuthnRequest est la requête d’authentification normalement envoyée par le SP. La Response est la réponse de l’IdP, qui peut contenir une ou plusieurs assertions. Les identifiants de requête et InResponseTo permettent de corréler les échanges SP-initiated.

Initiation et bindings¶

• SP-initiated SSO : l’utilisateur commence à l’application ; le SP crée une AuthnRequest et redirige le navigateur vers l’IdP. Cela facilite la corrélation et le ciblage vers l’application demandée.
• IdP-initiated SSO : l’utilisateur commence sur le portail IdP ; l’IdP envoie une réponse au SP sans AuthnRequest corrélée. C’est pratique pour un portail, mais il faut notamment éviter les risques de login-CSRF / confused deputy et valider strictement destinataire, audience et état applicatif.
• HTTP-Redirect binding : messages, typiquement AuthnRequest, transportés dans une redirection HTTP, avec encodage et signature selon le profil.
• HTTP-POST binding : message encodé dans un formulaire HTML soumis par le navigateur, souvent utilisé pour la Response contenant l’assertion.

sequenceDiagram
    actor U as Utilisateur
    participant B as Navigateur
    participant SP as Application (SP)
    participant IDP as Keycloak (IdP)
    U->>SP: Accède à une ressource
    SP-->>B: Redirection avec AuthnRequest (HTTP-Redirect)
    B->>IDP: AuthnRequest
    IDP->>U: Authentification / MFA
    U->>IDP: S'authentifie
    IDP-->>B: Formulaire contenant SAML Response (HTTP-POST)
    B->>SP: POST ACS (Assertion Consumer Service)
    SP->>SP: Vérifie signature, issuer, audience, destinataire, dates et corrélation
    SP-->>U: Session locale et ressource autorisée

Métadonnées, signatures et chiffrement¶

Les métadonnées SAML sont un document XML décrivant un IdP ou un SP : entity ID, endpoints (SSO, SLO, ACS) et clés/certificats. Les importer aide à configurer l’échange, mais les valeurs doivent être vérifiées : un fichier de métadonnées n’est pas automatiquement digne de confiance. Distribuez-le par un canal authentifié et planifiez le renouvellement des certificats.

Une signature XML assure l’intégrité et l’origine du message ou de l’assertion selon ce qui est signé. La vérification doit être faite par une bibliothèque SAML robuste, en respectant les règles de canonicalisation et en évitant les attaques de type XML Signature Wrapping. Le chiffrement XML protège la confidentialité de l’assertion en transit ; il ne remplace pas la signature ni TLS. Une clé privée de déchiffrement et les certificats de confiance doivent être protégés et renouvelés. Évitez toute validation XML « maison ».

NameID et attributs¶

Les formats NameID courants comprennent persistent (identifiant stable spécifique à la relation), transient (éphémère), emailAddress (adresse électronique) et unspecified. Le choix dépend du besoin de corrélation et de confidentialité ; une adresse email peut changer et n’est pas toujours un identifiant fiable.

Les attributs peuvent porter nom, email, groupes ou rôles, avec des noms et formats définis par le contrat de l’application. Limitez les attributs divulgués au strict nécessaire. Le SP doit gérer l’absence, le type et les changements de valeur, et ne doit pas convertir automatiquement une chaîne d’attribut en privilège sans politique explicite.

Pour configurer un client dans Keycloak et importer des métadonnées, consulter le guide pratique et les concepts Keycloak.