SAML Basics
Last updated
Last updated
Security Assertion Markup Language (SAML) permet aux fournisseurs d'identité (IdP) d'être utilisés pour envoyer des informations d'identification d'autorisation aux fournisseurs de services (SP), facilitant la connexion unique (SSO). Cette approche simplifie la gestion de plusieurs connexions en permettant l'utilisation d'un seul ensemble d'informations d'identification sur plusieurs sites Web. Elle exploite XML pour la communication normalisée entre les IdP et les SP, liant l'authentification de l'identité de l'utilisateur à l'autorisation de service.
SAML est conçu pour offrir aux entreprises un plus grand contrôle sur la sécurité de la connexion SSO.
OAuth est conçu pour être plus adapté aux mobiles, utilise JSON et est un effort collaboratif d'entreprises telles que Google et Twitter.
Pour plus de détails, consultez l'article complet sur 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 :
Tentative d'accès aux ressources : L'utilisateur tente d'accéder à une ressource protégée.
Génération de la demande SAML : Le SP ne reconnaît pas l'utilisateur et génère une demande SAML.
Redirection vers l'IdP : L'utilisateur est redirigé vers l'IdP, la demande SAML passant par le navigateur de l'utilisateur.
Réception de la demande par l'IdP : L'IdP reçoit la demande SAML.
Authentification à l'IdP : L'IdP authentifie l'utilisateur.
Validation de l'utilisateur : L'IdP valide la légitimité de l'utilisateur pour accéder à la ressource demandée.
Création de la réponse SAML : L'IdP génère une réponse SAML contenant les assertions nécessaires.
Redirection vers l'URL ACS du SP : L'utilisateur est redirigé vers l'URL du service de consommation d'assertions (ACS) du SP.
Validation de la réponse SAML : L'ACS valide la réponse SAML.
Accès aux ressources accordé : L'accès à la ressource initialement demandée est accordé.
Considérons le scénario où un utilisateur demande l'accès à une ressource sécurisée sur https://shibdemo-sp1.test.edu/secure/. Le SP identifie l'absence d'authentification et génère une demande SAML :
Le SAML Request brut ressemble à ceci:
Les éléments clés de cette demande comprennent :
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.
Après la génération de la demande SAML, le SP répond avec une redirection 302, 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.
Vous pouvez trouver une réponse SAML complète ici. Les composants clés de la réponse comprennent :
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étaille les conditions telles que 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.
Après la réponse SAML, le processus comprend une redirection 302 de l'IdP. Cela conduit à une demande POST vers l'URL du Service de Consommation d'Assertion (ACS) du Fournisseur de Services. La demande POST inclut les paramètres RelayState et SAMLResponse. Le ACS est responsable du traitement et de la validation de la réponse SAML.
Après réception de la demande POST et 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 requête GET vers l'endpoint /secure/ et une réponse 200 OK, indiquant un accès réussi à la ressource.
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 à n'importe quel objet XML, pas seulement aux éléments de réponse. Voici les principaux types de signatures XML :
Une Signature XML se compose d'éléments essentiels comme indiqué :
Chaque élément Reference signifie une ressource spécifique signée, identifiable par l'attribut URI.
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:
Dans une signature enveloppée, l'élément ds:Transform spécifie qu'elle est enveloppée à travers l'algorithme enveloped-signature.
Signature Enveloppante: Contrairement aux signatures enveloppées, les signatures enveloppantes enveloppent la ressource signée.
Exemple:
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:
En conclusion, les Signatures XML offrent des moyens flexibles de sécuriser les documents XML, chaque type répondant à des besoins structurels et de sécurité différents.
