Configurer les options de fournisseur d’identité SAML avec Azure Active Directory B2C

Article
03/27/2023

Azure Active Directory B2C (Azure AD B2C) prend en charge la fédération avec des fournisseurs d’identité SAML 2.0. Cet article décrit comment analyser les assertions de sécurité et les options de configuration disponibles lors de l’activation d’une connexion avec un fournisseur d’identité SAML.

Avant de commencer, utilisez le sélecteur Choisir un type de stratégie pour choisir le type de stratégie que vous configurez. Azure Active Directory B2C offre deux possibilités pour définir la façon dont les utilisateurs interagissent avec vos applications : via des flux utilisateurs prédéfinis ou via des stratégies personnalisées entièrement configurables. La procédure donnée dans cet article est différente pour chaque méthode.

Cette fonctionnalité est disponible uniquement pour les stratégies personnalisées. Pour accéder aux étapes de configuration, sélectionnez Stratégie personnalisée dans le sélecteur précédent.

Mappage des revendications

L’élément OutputClaims contient une liste de revendications que le fournisseur d’identité SAML retourne. Il se peut que vous deviez mapper le nom de la revendication définie dans votre stratégie au nom défini dans le fournisseur d’identité. Contactez votre fournisseur d’identité pour obtenir la liste des revendications (assertions). Vous pouvez également vérifier le contenu de la réponse SAML que votre fournisseur d’identité retourne. Pour plus d’informations, consultez Déboguer des messages SAML. Pour ajouter une revendication, commencez par définir une revendication, puis ajoutez celle-ci à la collection de revendications de sortie.

Vous pouvez également inclure des revendications qui ne sont pas retournées par le fournisseur d’identité, pour autant que vous définissiez l’attribut DefaultValue. La valeur par défaut peut être statique ou dynamique, utilisant des revendications de contexte.

L’élément de revendication de sortie contient les attributs suivants :

ClaimTypeReferenceId est la référence à un type de revendication.
PartnerClaimType : nom de la propriété qui apparaît dans l’assertion SAML.
DefaultValue est une valeur par défaut prédéfinie. Si la revendication est vide, la valeur par défaut est utilisée. Vous pouvez également vous servir d’un outil de résolution des revendications avec une valeur contextuelle, telle que l’ID d’application ou l’adresse IP de l’utilisateur.

Nom d'objet

Pour lire l’assertion SAML NamedId dans l’Objet comme une revendication normalisée, définissez la revendication PartnerClaimType sur la valeur de l’attribut SPNameQualifier. Si l’attribut SPNameQualifier n’est pas présenté, définissez la revendication PartnerClaimType sur la valeur de l’attribut NameQualifier.

Assertion SAML :

<saml:Subject>
  <saml:NameID SPNameQualifier="http://your-idp.com/unique-identifier" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">david@contoso.com</saml:NameID>
  <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData InResponseTo="_cd37c3f2-6875-4308-a9db-ce2cf187f4d1" NotOnOrAfter="2020-02-15T16:23:23.137Z" Recipient="https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
    </SubjectConfirmation>
  </saml:SubjectConfirmation>
</saml:Subject>

Revendication de sortie :

<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="http://your-idp.com/unique-identifier" />

Si les attributs SPNameQualifier ou NameQualifier ne sont pas présentés dans l’assertion SAML, définissez la revendication PartnerClaimType sur assertionSubjectName. Assurez-vous que NameId est la première valeur dans l’assertion XML. Lorsque vous définissez plusieurs assertion, Azure AD B2C sélectionne la valeur d’objet de la dernière assertion.

Configurer des liaisons de protocole SAML

Les demandes SAML sont envoyées au fournisseur d’identité comme spécifié dans l’élément SingleSignOnService des métadonnées du fournisseur d’identité. La plupart des demandes d’autorisation des fournisseurs d’identité sont transportées directement dans la chaîne de requête d’URL d’une requête HTTP GET (car les messages sont relativement courts). Pour savoir comment configurer les liaisons pour les deux demandes SAML, consultez la documentation de votre fournisseur d’identité.

Le code XML suivant est un exemple de service d’authentification unique de métadonnées Microsoft Entra avec deux liaisons. La requête HTTP-Redirect prend le pas sur la requête HTTP-POST, car elle apparaît en premier dans les métadonnées du fournisseur d’identité SAML.

<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
</IDPSSODescriptor>

Assertion Consumer Service

Assertion consumer service (ou ACS) est l’emplacement auquel les réponses SAML du fournisseur d’identité sont envoyées et reçues par Azure AD B2C. Les réponses SAML sont transmises à Azure AD B2C via une liaison HTTP POST. L’emplacement des services ACS pointe vers la stratégie de base de votre partie de confiance. Par exemple, si la stratégie de confiance est B2C_1A_signup_signin, ACS est la stratégie de base de la B2C_1A_signup_signin, telle que B2C_1A_TrustFrameworkBase.

Le code XML suivant est un exemple d’assertion consumer service de métadonnées de stratégie Azure AD B2C.

<SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-tenant.b2clogin.com/your-tenant/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" index="0" isDefault="true"/>
</SPSSODescriptor>

Configurer la signature de demande SAML

Azure AD B2C signe toutes les demandes d’authentification sortantes à l’aide de la clé de chiffrement SamlMessageSigning. Pour désactiver la signature de demande SAML, définissez la valeur de WantsSignedRequests sur false . Si la métadonnée est définie sur false, les paramètres SigAlg et Signature (chaîne de requête ou paramètre de publication) sont omis de la demande.

Cette métadonnée contrôle également l’attribut AuthnRequestsSigned inclus avec la métadonnée du profil technique Azure AD B2C partagé avec le fournisseur d’identité. Azure AD B2C ne signe pas la demande si la valeur de WantsSignedRequests dans les métadonnées du profil technique est définie sur false et si les métadonnées du fournisseur identité WantAuthnRequestsSigned sont définies sur false ou ne sont pas spécifiées.

L’exemple suivant supprime la signature du certificat SAML.

<Metadata>
  ...
  <Item Key="WantsSignedRequests">false</Item>
</Metadata>

Algorithme de signature

Azure AD B2C utilise Sha1 pour signer la demande SAML. Utilisez les métadonnées XmlSignatureAlgorithm pour configurer l’algorithme à utiliser. Les valeurs possibles sont Sha256, Sha384, Sha512 ou Sha1 (par défaut). Ces métadonnées contrôlent la valeur du paramètre SigAlg (chaîne de requête ou paramètre d’envoi) dans la demande SAML. Veillez à configurer l’algorithme de signature des deux côtés avec la même valeur. Utilisez uniquement l’algorithme pris en charge par votre certificat.

Inclure les informations sur la clé

Lorsque le fournisseur d’identité indique que la liaison Azure AD B2C a la valeur HTTP-POST, Azure ad B2C inclut la signature et l’algorithme dans le corps de la demande SAML. Vous pouvez également configurer Microsoft Entra ID pour inclure la clé publique du certificat lorsque la liaison a la valeur HTTP-POST. Utilisez la métadonnée IncludeKeyInfo pour définir sur true ou false. Dans l’exemple suivant, Microsoft Entra ID n’inclut pas la clé publique du certificat.

<Metadata>
  ...
  <Item Key="IncludeKeyInfo">false</Item>
</Metadata>

Configurer l’ID de nom de demande SAML

L’élément <NameID> de demande d’autorisation SAML indique le format d’identificateur de nom SAML. Cette section décrit la configuration par défaut et explique comment personnaliser l’élément ID de nom.

Nom d’utilisateur par défaut

Pendant le parcours utilisateur pour la connexion, une application par partie de confiance peut cibler un utilisateur spécifique. Azure AD B2C vous permet d’envoyer un nom d’utilisateur de prédilection au fournisseur d’identité SAML. L’élément InputClaims est utilisé pour envoyer un NameId dans l’Objet de la demande d’autorisation SAML.

Pour inclure l’ID de nom de l’objet dans la demande d’autorisation, ajoutez l’élément <InputClaims> suivant immédiatement après les <CryptographicKeys>. La valeur de PartnerClaimType doit être subject.

<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" />
</InputClaims>

Dans cet exemple, Azure AD B2C envoie la valeur de la revendication signInName avec NameId dans l’Objet de la demande d’autorisation SAML.

<samlp:AuthnRequest ... >
  ...
  <saml:Subject>
    <saml:NameID>sam@contoso.com</saml:NameID>
  </saml:Subject>
</samlp:AuthnRequest>

Vous pouvez utiliser des revendications de contexte telles que {OIDC:LoginHint} pour remplir la valeur de la revendication.

<Metadata>
  ...
  <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
</Metadata>
  ...
<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" DefaultValue="{OIDC:LoginHint}" AlwaysUseDefaultValue="true" />
</InputClaims>

Format de stratégie d’ID de nom

Par défaut, la demande d’autorisation SAML spécifie la stratégie urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified. Cet ID de nom indique que tout type d’identificateur pris en charge par le fournisseur d’identité pour l’objet demandé peut être utilisé.

Pour modifier ce comportement, consultez la documentation de votre fournisseur d’identité qui contient des indications concernant les stratégies d’ID de nom prises en charge. Ajoutez ensuite la métadonnée NameIdPolicyFormat dans le format de stratégie correspondant. Par exemple :

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
</Metadata>

La demande d’autorisation SAML suivante contient la stratégie d’ID de nom.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</samlp:AuthnRequest>

Autoriser la création de comptes

Si vous spécifiez le format de stratégie d’ID de nom, vous pouvez également spécifier la propriété AllowCreate de NameIDPolicy pour indiquer si le fournisseur d’identité est autorisé à créer un compte au cours du processus de connexion. Pour obtenir des indications, consultez la documentation de votre fournisseur d’identité.

Azure AD B2C omet la propriété AllowCreate par défaut. Vous pouvez changer ce comportement à l’aide la métadonnée NameIdPolicyAllowCreate. La valeur de cette métadonnée est true ou false.

L’exemple suivant montre comment définir la propriété AllowCreate de l’élément NameIDPolicy sur true.

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
  <Item Key="NameIdPolicyAllowCreate">true</Item>
</Metadata>

L’exemple suivant illustre une demande d’autorisation avec la propriété AllowCreate de l’élément NameIDPolicy dans la demande d’autorisation.

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy 
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" 
      AllowCreate="true" />
</samlp:AuthnRequest>

Forcer l’authentification

Vous pouvez forcer l’IDP SAML externe à demander à l’utilisateur une authentification en passant la propriété ForceAuthN dans la requête d’authentification SAML. Votre fournisseur d’identité doit également prendre en charge cette propriété.

La propriété ForceAuthN est une valeur booléenne true ou false. Par défaut, Azure AD B2C définit la valeur ForceAuthN sur false. Si la session est ensuite réinitialisée (par exemple, à l’aide de prompt=login dans OIDC), la valeur ForceAuthN est alors définie sur true. La définition de la métadonnée ForceAuthN sur true force la valeur de toutes les requêtes à l’IDP externe.

L'exemple suivant illustre la propriété ForceAuthN définie sur true :

<Metadata>
  ...
  <Item Key="ForceAuthN">true</Item>
  ...
</Metadata>

L’exemple suivant illustre la propriété ForceAuthN dans une requête d’autorisation :

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ForceAuthN="true">
  ...
</samlp:AuthnRequest>

Nom du fournisseur

Vous pouvez éventuellement inclure l’attribut ProviderName dans la demande d’autorisation SAML. Définissez la métadonnée ProviderName comme indiqué ci-dessous pour inclure le nom du fournisseur pour toutes les demandes adressées à l’IDP SAML externe. L'exemple suivant illustre la propriété ProviderName définie sur Contoso app :

<Metadata>
  ...
  <Item Key="ProviderName">Contoso app</Item>
  ...
</Metadata>

L’exemple suivant illustre la propriété ProviderName dans une requête d’autorisation :

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ProviderName="Contoso app">
  ...
</samlp:AuthnRequest>

Inclure les références de classe de contexte d’authentification

Une demande d’autorisation SAML peut contenir un élément AuthnContext qui spécifie le contexte d’une demande d’autorisation. L’élément peut contenir une référence de classe de contexte d’authentification, indiquant au fournisseur d’identité SAML le mécanisme d’authentification à présenter à l’utilisateur.

Pour configurer les références de classe de contexte d’authentification, ajoutez la métadonnée IncludeAuthnContextClassReferences. Dans la valeur, spécifiez une ou plusieurs références d’URI identifiant des classes de contexte d’authentification. Spécifiez plusieurs URI sous la forme d’une liste délimitée par des virgules. Pour obtenir des conseils concernant les URI AuthnContextClassRef pris en charge, consultez la documentation de votre fournisseur d’identité.

L’exemple suivant permet aux utilisateurs de se connecter avec un nom d’utilisateur et un mot de passe, ainsi que de se connecter avec un nom d’utilisateur et un mot de passe via une session protégée (SSL/TLS).

<Metadata>
  ...
  <Item Key="IncludeAuthnContextClassReferences">urn:oasis:names:tc:SAML:2.0:ac:classes:Password,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</Item>
</Metadata>

La demande d’autorisation SAML suivante contient les références de classe de contexte d’authentification.

<samlp:AuthnRequest ... >
  ...
  <samlp:RequestedAuthnContext>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

Inclure des données personnalisées dans la demande d’autorisation

Vous pouvez éventuellement inclure des éléments d’extension de message de protocole qui sont approuvés tant par Azure AD B2C que par votre fournisseur d’identité. L’extension est présentée au format XML. Vous incluez des éléments d’extension en ajoutant des données XML à l’intérieur de l’élément CDATA <![CDATA[Your Custom XML]]>. Pour voir si l’élément d’extensions est pris en charge, consultez la documentation de votre fournisseur d’identité.

L’exemple suivant illustre l’utilisation de données d’extension :

<Metadata>
  ...
  <Item Key="AuthenticationRequestExtensions"><![CDATA[
            <ext:MyCustom xmlns:ext="urn:ext:custom">
              <ext:AssuranceLevel>1</ext:AssuranceLevel>
              <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
            </ext:MyCustom>]]></Item>
</Metadata>

Notes

Conformément à la spécification SAML, les données d’extension doivent être du code XML qualifié par un espace de noms (par exemple, « urn:ext:custom » illustré dans l’exemple), et il ne doit pas s’agir de l’un des espaces de noms spécifiques de SAML.

Avec l’extension de message de protocole SAML, la réponse SAML ressemble à l’exemple suivant :

<samlp:AuthnRequest ... >
  ...
  <samlp:Extensions>
    <ext:MyCustom xmlns:ext="urn:ext:custom">
      <ext:AssuranceLevel>1</ext:AssuranceLevel>
      <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
    </ext:MyCustom>
  </samlp:Extensions>
</samlp:AuthnRequest>

Exiger des réponses SAML signées

Azure AD B2C exige la signature de toutes les assertions entrantes. Vous pouvez supprimer cette exigence en définissant la valeur de WantsSignedAssertions sur false. Dans ce cas, le fournisseur d’identité ne doit pas signer les assertions, mais, même s’il le fait, Azure AD B2C ne valide pas la signature.

La métadonnée WantsSignedAssertions contrôle l’indicateur de métadonnée SAML WantsAssertionsSigned inclus dans la métadonnée du profil technique Azure AD B2C partagé avec le fournisseur d’identité.

<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

Si vous désactivez la validation des assertions, vous pouvez également désactiver la validation de signature de message de réponse. Définissez la métadonnée ResponsesSigned sur false. Dans ce cas, le fournisseur d’identité ne devrait pas signer le message de réponse SAML, mais, même s’il le fait, Azure AD B2C ne valide pas la signature.

L’exemple suivant supprime tant le message que la signature d’assertion :

<Metadata>
  ...
  <Item Key="WantsSignedAssertions">false</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

Exiger des réponses SAML chiffrées

Pour exiger le chiffrement de toutes les assertions entrantes, définissez la métadonnée WantsEncryptedAssertions . Quand le chiffrement est requis, le fournisseur d’identité utilise une clé publique d’un certificat de chiffrement dans un profil technique Azure AD B2C. Azure AD B2C déchiffre l’assertion de réponse à l’aide de la partie privée du certificat de chiffrement.

Si vous activez le chiffrement des assertions, il se peut que vous deviez également désactiver la validation de signature de réponse (pour plus d’informations, consultez Exiger des réponses SAML signées).

Si la valeur de la métadonnée WantsEncryptedAssertionsest, la métadonnée du profil technique Azure AD B2C inclut la section chiffrementtrue. Le fournisseur d’identité lit les métadonnées et chiffre l’assertion de réponse SAML avec la clé publique fournie dans les métadonnées du profil technique Azure AD B2C.

L’exemple suivant illustre la section Descripteur de clé des métadonnées SAML utilisées pour le chiffrement :

<SPSSODescriptor AuthnRequestsSigned="true"  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="encryption">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
      <X509Data>
        <X509Certificate>valid certificate</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
  ...
</SPSSODescriptor>

Pour chiffrer l’assertion de réponse SAML :

Créez une clé de stratégie avec un identificateur unique. Par exemple : B2C_1A_SAMLEncryptionCert.
Dans la collection CryptographicKeys de votre profil technique SAML. Définissez la valeur de StorageReferenceId sur le nom de la clé de stratégie que vous avez créée à la première étape. L’ID SamlAssertionDecryption indique l’utilisation de la clé de chiffrement pour chiffrer et déchiffrer l’assertion de la réponse SAML.
```
<CryptographicKeys>
        ...
  <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
</CryptographicKeys>
```
Affectez la valeur true à l’élément de métadonnées de profil technique WantsEncryptedAssertions.
```
<Metadata>
  ...
  <Item Key="WantsEncryptedAssertions">true</Item>
</Metadata>
```
Mettez à jour le fournisseur d’identité avec la nouvelle métadonnée de profil technique Azure AD B2C. Vous devez voir le KeyDescriptor avec la propriété use définie sur encryption contenant la clé publique de votre certificat.

Activer l’utilisation des revendications de contexte

Dans la collection de revendications d’entrée et de sortie, vous pouvez inclure des revendications qui ne sont pas retournées par le fournisseur d’identité tant que vous définissez l’attribut DefaultValue. Vous pouvez également utiliser des revendications de contexte à inclure dans le profil technique. Pour utiliser une revendication de contexte :

Ajoutez un type de revendication à l’élément ClaimsSchema dans BuildingBlocks.
Ajoutez une revendication de sortie à la collection d’entrée ou de sortie. Dans l’exemple suivant, la première revendication définit la valeur du fournisseur d’identité. La deuxième revendication utilise les revendications de contexted’adresse IP de l’utilisateur.
```
<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" AlwaysUseDefaultValue="true" />
  <OutputClaim ClaimTypeReferenceId="IpAddress" DefaultValue="{Context:IPAddress}" AlwaysUseDefaultValue="true" />
</OutputClaims>
```

Désactiver une sortie unique

Lors d’une demande de déconnexion d’application, Azure AD B2C tente de se déconnecter de votre fournisseur d’identité SAML. Pour plus d’informations, consultez Déconnexion de la session Azure AD B2C. Pour désactiver le comportement de Single Logout, définissez les métadonnées SingleLogoutEnabled sur false.

<Metadata>
  ...
  <Item Key="SingleLogoutEnabled">false</Item>
</Metadata>

Déboguer le protocole SAML

Pour faciliter la configuration et le débogage de la fédération avec un fournisseur d’identité SAML, vous pouvez utiliser une extension de navigateur pour le protocole SAML, telle que l’Extension SAML DevTools pour Chrome, le Traceur SAML pour Firefox ou les Outils de développement Microsoft Edge ou IE.

Ces outils vous permettent de vérifier l’intégration entre Azure AD B2C et votre fournisseur d’identité SAML. Par exemple :

Vérifiez si la demande SAML contient une signature, et déterminez l’algorithme utilisé pour la connexion à la demande d’autorisation.
Récupérez les revendications (assertions) sous la section AttributeStatement.
Vérifiez si le fournisseur d’identité retourne un message d’erreur.
Vérifiez si la section d’assertion est chiffrée.

Exemples de messages de requête et de réponses SAML

Security Assertion Markup Language (SAML) est une norme ouverte pour l’échange de données d’authentification et d’autorisation entre un fournisseur d’identité et un fournisseur de services. Quand Azure AD B2C fédère avec un fournisseur d’identité SAML, il fait office de fournisseur de services qui envoie une demande SAML au fournisseur d’identité SAML et qui attend une réponse SAML.

Une réponse SAML réussie contient des assertions de sécurité qui sont des instructions effectuées par les fournisseurs d’identité SAML externes. Azure AD B2C analyse et mappe les assertions en revendications.

Requête d’autorisation

Pour demander une authentification utilisateur, Azure AD B2C envoie un élément AuthnRequest au fournisseur d’identité SAML externe. Exemple de AuthnRequest SAML 2.0 :

<samlp:AuthnRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    ID="_11111111-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:10:00.0000000Z" 
    Destination="https://fabrikam.com/saml2" 
    ForceAuthn="false" 
    IsPassive="false" 
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
    AssertionConsumerServiceURL="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    ProviderName="https://fabrikam.com" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
</samlp:AuthnRequest>

response

Lorsqu’une authentification demandée se termine, le fournisseur d’identité SAML externe publie une réponse au point de terminaison d’assertion consumer service Azure AD B2C. Exemple de réponse à une tentative d’ouverture de session réussie :

<samlp:Response 
    ID="_98765432-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:11:30.0000000Z" 
    Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    InResponseTo="_11111111-0000-0000-0000-000000000000" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://fabrikam.com/
    </Issuer>
    <samlp:Status>
        <samlp:StatusCode 
            Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <Assertion 
        ID="_55555555-0000-0000-0000-000000000000" 
        IssueInstant="2023-03-20T07:40:45.505Z" 
        Version="2.0" 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>https://fabrikam.com/</Issuer>
        <Signature 
            xmlns="http://www.w3.org/2000/09/xmldsig#">
            ...
        </Signature>
        <Subject>
            <NameID 
                Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEFG
            </NameID>
            ...
        </Subject>
        <AttributeStatement>
            <Attribute Name="uid">
                <AttributeValue>12345</AttributeValue>
            </Attribute>
            <Attribute Name="displayname">
                <AttributeValue>David</AttributeValue>
            </Attribute>
            <Attribute Name="email">
                <AttributeValue>david@contoso.com</AttributeValue>
            </Attribute>
            ....
        </AttributeStatement>
        <AuthnStatement 
            AuthnInstant="2023-03-20T07:40:45.505Z" 
            SessionIndex="_55555555-0000-0000-0000-000000000000">
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>

Demande de déconnexion

Lors d’une demande de déconnexion d’application, Azure AD B2C tente de se déconnecter de votre fournisseur d’identité SAML. Azure AD B2C envoie un message LogoutRequest au fournisseur d’identité externe pour indiquer qu’une session a été terminée. L’extrait suivant illustre un exemple d’élément LogoutRequest .

La valeur de l’élément NameID correspond au NameID de l’utilisateur en cours de déconnexion. L’élément SessionIndex correspond à l’attribut SessionIndex de AuthnStatement dans la réponse SAML de connexion.

<samlp:LogoutRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    ID="_22222222-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T08:21:07.3679354Z" 
    Destination="https://fabrikam.com/saml2/logout" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
    <saml:NameID>ABCDEFG</saml:NameID>
    <samlp:SessionIndex>_55555555-0000-0000-0000-000000000000</samlp:SessionIndex>
</samlp:LogoutRequest>

Étapes suivantes

Découvrez comment diagnostiquer les problèmes liés à vos stratégies personnalisées à l’aide d’Application Insights.

Partager via