SAML 2.0

Qu'est-ce que SAML ?

En général, lorsque vous commencez à travailler dans une nouvelle entreprise, vous recevez une adresse électronique professionnelle que vous utilisez pour vous connecter aux applications auxquelles vous avez droit. Le processus d'authentification peut impliquer une redirection vers une page web hébergée par un produit comme IBM Security Verify SaaS ou IBM Security Verify Access, où il peut vous être demandé d'effectuer certaines étapes supplémentaires. Par exemple, enregistrer des facteurs d'authentification supplémentaires pour l'AMF ou consentir à des conditions d'utilisation, etc. La magie du processus d'authentification est généralement assurée par un protocole de fédération - SAML ou OpenID Connect. Cet article se concentre sur le protocole SAML. Cette norme est largement utilisée dans les grandes entreprises et dans la plupart des applications SaaS.

Security Assertion Markup Language (SAML) est une norme ouverte basée sur XML pour le transfert de données d'identité entre deux parties : le fournisseur d'identité IdP et le fournisseur de services (SP).

Fournisseur d'identité- Effectue l'authentification et construit un jeton d'identité d'utilisateur (appelé assertion SAML), le signe et le crypte éventuellement, puis le transmet au fournisseur d'accès. Ce jeton contient les attributs de l'utilisateur (comme l'adresse électronique, le nom de famille, etc.) et éventuellement un niveau d'autorisation.

Fournisseur de services- Il fait confiance au fournisseur d'identité et est en mesure de vérifier cryptographiquement le jeton d'identité de l'utilisateur.

Dans l'exemple ci-dessus, IBM Security Verify est l' IdP et l'application est le SP.

IBM Security Verify peut agir en tant qu' IdP et/ou SP. En d'autres termes, vous pouvez ajouter un fournisseur d'identité externe à votre locataire IBM Security Verify (au lieu d'utiliser le Cloud Directory natif) qui authentifie l'utilisateur. Verify fait confiance à l' IdP et est en mesure de traiter le jeton d'identité, de le normaliser et de mettre les informations d'attribut à la disposition des applications en aval dans un autre jeton d'identité SAML.

Avantages de l'authentification SAML

1. Amélioration de l'expérience utilisateur- Les utilisateurs se connectent une seule fois au navigateur web et peuvent accéder à de multiples applications pendant toute la durée de vie du navigateur.
2. Méthode sécurisée de transmission des données de l'utilisateur- Le jeton d'identité est signé par une clé cryptographique et peut être crypté en option. Cela le rend inviolable et permet de répondre aux préoccupations en matière de protection de la vie privée. Les données de l'utilisateur sont généralement envoyées par le biais du navigateur au PS.
3. Option de ne pas répliquer les données de l'utilisateur- Les fournisseurs de services n'ont pas besoin de stocker les informations de l'utilisateur car lorsque l'utilisateur s'authentifie à nouveau, le jeton d'identité SAML contient ce dont le fournisseur de services a besoin.
4. Broker pour la prise en charge de plusieurs fournisseurs d'identité - IBM Security Verify offre la possibilité de configurer plusieurs fournisseurs d'identité fédérés SAML pour prendre en charge les organisations qui choisissent de regrouper les utilisateurs dans différents registres. Par exemple, les utilisateurs privilégiés, les employés réguliers et les consommateurs.

Fonctionnement de SAML

Il y a deux parties : le fournisseur d'identité IdP et le fournisseur de services (SP). Par souci de clarté, supposons que le fournisseur d'identité soit IBM Security Verify et le fournisseur de service JKE Portal. Le flux SSO initié par le fournisseur de services est décrit ci-dessous.

• L'utilisateur tente de se connecter au portail JKE
• Le portail JKE envoie une demande d'authentification par l'intermédiaire du navigateur. C'est ce qu'on appelle une demande d'authentification AuthnRequest ). Il s'agit d'un document XML signé et éventuellement crypté par le PS. En plus de l' AuthnRequest, une variable RelayState est générée de manière aléatoire et incluse. Cela permet d'éviter les attaques par rejeu dans le flux.

<AuthnRequest xmlns="urn:oasis:names:tc:SAML:2.0:protocol"
              xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
              Version="2.0"
              ID="_991d037ede1f9b46e8332b19b7dc203bc3d93f3bd8"
              IssueInstant="2021-02-03T15:25:50.428Z"
              Destination="https://tenant.verify.ibm.com/saml/sps/saml20ip/saml20/12345/login"
              AssertionConsumerServiceURL="https://verifyapp.mybluemix.net/assert"
              ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
              ForceAuthn="false"
              >
    <saml:Issuer>verify-app</saml:Issuer>
    <NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
                  AllowCreate="true"
                  />
    <RequestedAuthnContext Comparison="exact">
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:1.0:am:password</saml:AuthnContextClassRef>
    </RequestedAuthnContext>
</AuthnRequest>

L' AuthnRequest peut être envoyé dans le cadre d'un paramètre de chaîne de requête (appelé SAML Redirect Binding) ou d'un FORM HTML auto-soumis (appelé SAML Post Binding). Il existe d'autres fixations (par exemple, la fixation de l'artefact), mais elles sont rarement utilisées.

• IBM Security Verify valide l' AuthnRequest et vérifie que l'utilisateur s'est authentifié. Si ce n'est pas le cas, l'utilisateur est soumis à un processus d'authentification configuré, qui peut ou non s'appuyer sur le protocole SAML.
• IBM Security Verify construit l'assertion SAML, qui contient les informations relatives à l'identité de l'utilisateur. Cette assertion est contenue dans une enveloppe XML appelée réponse d'authentification AuthnResponse ). L'assertion et/ou la AuthnResponse peuvent être signées et éventuellement cryptées.
• IBM Security Verify crée un formulaire HTML auto-soumis qui publie cette AuthnResponse et le RelayState (envoyé à l'étape de la demande) sur le portail JKE.

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                Destination="https://verifyapp.mybluemix.net/assert"
                ID="FIMRSP_68837a65-0177-1b14-a613-9a254f0f98bd"
                InResponseTo="_991d037ede1f9b46e8332b19b7dc203bc3d93f3bd8"
                IssueInstant="2021-02-03T15:29:43Z" Version="2.0"
                xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://tenant.verify.ibm.com/saml/sps/saml20ip/saml20/12345
    </saml:Issuer>
    <ds:Signature Id="uuid68837a66-0177-17db-bf45-9a254f0f98bd">
        <ds:SignedInfo>
...

• Le portail JKE valide les données soumises, extrait les informations utilisateur pertinentes et connecte l'utilisateur.

Il y a quelques caractéristiques importantes à noter ci-dessus.

• ID : Nouvel identifiant généré pour le message
• IssueInstant: Horodatage de la génération du message
• InResponseTo: L'identifiant de l' AuthnRequest qui a initié le flux
• AssertionConsumerServiceURL: Point d'accès auquel la réponse SAML est envoyée par IBM Security Verify. Il peut y avoir plusieurs points de terminaison autorisés configurés sur l'ISV dans la configuration de l'application SAML.
• Émetteur : l'entité SAML qui émet le message. Il est utilisé pour identifier l' IdP/SP à la fois dans IBM Security Verify et dans l'application.

Il existe d'autres contraintes qui régissent la validité du message, etc.

Comment intégrer votre partenaire SAML à IBM Security Verify?

IBM Security Verify peut agir à la fois comme fournisseur d'identité et comme fournisseur de services.

• Configurer une source d'identité SAML
• Configurer une application SAML

💎

Vivek Shankar, architecte produit