Vue d'ensemble de SAML

Security Assertion Markup Language (SAML) permet aux fournisseurs d'identité (IdP) d'être utilisés pour envoyer des informations d'autorisation aux fournisseurs de services (SP), facilitant ainsi l'authentification unique (SSO). Cette approche simplifie la gestion de plusieurs connexions en permettant d'utiliser un seul ensemble d'informations d'identification sur plusieurs sites web. Elle utilise XML pour une communication standardisée entre les IdP et les SP, liant l'authentification de l'identité de l'utilisateur à l'autorisation de service.

Comparaison entre SAML et OAuth

• SAML est conçu pour offrir aux entreprises un meilleur contrôle sur la sécurité des connexions SSO.
• OAuth est conçu pour être plus adapté aux mobiles, utilise JSON et est un effort collaboratif d'entreprises comme Google et Twitter.

Flux d'authentification SAML

Pour plus de détails, consultez le post complet de https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Voici un résumé :

Le processus d'authentification SAML implique plusieurs étapes, comme illustré dans le schéma :

1. Tentative d'accès à la ressource : L'utilisateur essaie d'accéder à une ressource protégée.
2. Génération de la demande SAML : Le SP ne reconnaît pas l'utilisateur et génère une demande SAML.
3. Redirection vers l'IdP : L'utilisateur est redirigé vers l'IdP, la demande SAML passant par le navigateur de l'utilisateur.
4. L'IdP reçoit la demande : L'IdP reçoit la demande SAML.
5. Authentification à l'IdP : L'IdP authentifie l'utilisateur.
6. Validation de l'utilisateur : L'IdP valide la légitimité de l'utilisateur à accéder à la ressource demandée.
7. Création de la réponse SAML : L'IdP génère une réponse SAML contenant les assertions nécessaires.
8. Redirection vers l'URL ACS du SP : L'utilisateur est redirigé vers l'URL du Service Consommateur d'Assertions (ACS) du SP.
9. Validation de la réponse SAML : L'ACS valide la réponse SAML.
10. Accès à la ressource accordé : L'accès à la ressource initialement demandée est accordé.

Exemple de demande SAML

Considérons le scénario où un utilisateur demande l'accès à une ressource sécurisée à https://shibdemo-sp1.test.edu/secure/. Le SP identifie l'absence d'authentification et génère une demande SAML :

GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...

La requête SAML brute ressemble à ceci :

<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>

Les éléments clés de cette demande incluent :

• AssertionConsumerServiceURL : Spécifie où l'IdP doit envoyer la réponse SAML après l'authentification.
• Destination : L'adresse de l'IdP à laquelle la demande est envoyée.
• ProtocolBinding : Définit la méthode de transmission des messages du protocole SAML.
• saml:Issuer : Identifie l'entité qui a initié la demande.

Suite à la génération de la demande SAML, le SP répond avec un 302 redirect, dirigeant le navigateur vers l'IdP avec la demande SAML encodée dans l'en-tête Location de la réponse HTTP. Le paramètre RelayState maintient les informations d'état tout au long de la transaction, garantissant que le SP reconnaît la demande de ressource initiale lors de la réception de la réponse SAML. Le paramètre SAMLRequest est une version compressée et encodée de l'extrait XML brut, utilisant la compression Deflate et l'encodage base64.

Exemple de réponse SAML

Vous pouvez trouver une réponse SAML complète ici. Les composants clés de la réponse incluent :

• ds:Signature : Cette section, une signature XML, garantit l'intégrité et l'authenticité de l'émetteur de l'assertion. La réponse SAML dans l'exemple contient deux éléments ds:Signature, un pour le message et l'autre pour l'assertion.
• saml:Assertion : Cette partie contient des informations sur l'identité de l'utilisateur et éventuellement d'autres attributs.
• saml:Subject : Il spécifie le sujet principal de toutes les déclarations dans l'assertion.
• saml:StatusCode : Représente l'état de l'opération en réponse à la demande correspondante.
• saml:Conditions : Détails des conditions comme la durée de validité de l'assertion et le fournisseur de services spécifié.
• saml:AuthnStatement : Confirme que l'IdP a authentifié le sujet de l'assertion.
• saml:AttributeStatement : Contient des attributs décrivant le sujet de l'assertion.

Suite à la réponse SAML, le processus inclut un 302 redirect de l'IdP. Cela conduit à une demande POST vers l'URL du Service d'Assertion Consumer (ACS) du fournisseur de services. La demande POST inclut les paramètres RelayState et SAMLResponse. L'ACS est responsable du traitement et de la validation de la réponse SAML.

Après la réception de la demande POST et la validation de la réponse SAML, l'accès est accordé à la ressource protégée initialement demandée par l'utilisateur. Cela est illustré par une demande GET vers le point de terminaison /secure/ et une réponse 200 OK, indiquant un accès réussi à la ressource.

Signatures XML

Les signatures XML sont polyvalentes, capables de signer un arbre XML entier ou des éléments spécifiques à l'intérieur. Elles peuvent être appliquées à tout objet XML, pas seulement aux éléments de réponse. Voici les types clés de signatures XML :

Structure de base de la signature XML

Une signature XML se compose d'éléments essentiels comme montré :

<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>

Chaque élément Reference signifie une ressource spécifique signée, identifiable par l'attribut URI.

Types de signatures XML

1. Signature enveloppée : Ce type de signature est un descendant de la ressource qu'il signe, ce qui signifie que la signature est contenue dans la même structure XML que le contenu signé.

Exemple :

<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>

Dans une signature enveloppée, l'élément ds:Transform spécifie qu'il est enveloppé par l'algorithme enveloped-signature.

2. Signature enveloppante : Contrairement aux signatures enveloppées, les signatures enveloppantes enveloppent la ressource à signer.

Exemple :

<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>

3. Signature détachée : Ce type est séparé du contenu qu'il signe. La signature et le contenu existent indépendamment, mais un lien entre les deux est maintenu.

Exemple :

<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>

En conclusion, les signatures XML offrent des moyens flexibles de sécuriser les documents XML, chaque type répondant à différents besoins structurels et de sécurité.

Références

• https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/