Konfigurieren von SAML-Identitätsanbieteroptionen mit Azure Active Directory B2C

Dieses Feature ist nur für benutzerdefinierte Richtlinien verfügbar. Wählen Sie für Setupschritte im vorherigen Selektor die Option "Benutzerdefinierte Richtlinie " aus.

Anspruchszuordnung

Das OutputClaims-Element enthält eine Liste der Ansprüche, die vom SAML-Identitätsanbieter zurückgegeben werden. Sie müssen den Namen des in Ihrer Richtlinie definierten Anspruchs dem Namen zuordnen, der im Identitätsanbieter definiert ist. Überprüfen Sie Ihren Identitätsanbieter auf die Liste der Ansprüche (Assertionen). Sie können auch den Inhalt der SAML-Antwort überprüfen, die Ihr Identitätsanbieter zurückgibt. Weitere Informationen finden Sie unter Debuggen der SAML-Nachrichten. Um einen Anspruch hinzuzufügen, definieren Sie zuerst einen Anspruch, und fügen Sie dann den Anspruch der Ausgabeanspruchsauflistung hinzu.

Sie können auch Ansprüche einschließen, die nicht vom Identitätsanbieter zurückgegeben werden, solange Sie das DefaultValue Attribut festlegen. Der Standardwert kann statisch oder dynamisch sein, wobei Kontextansprüche verwendet werden.

Das Ausgabeanspruchselement enthält die folgenden Attribute:

• ClaimTypeReferenceId ist der Verweis auf einen Anspruchstyp.
• PartnerClaimType ist der Name der Eigenschaft, die in der SAML-Assertion angezeigt wird.
• DefaultValue ist ein vordefinierter Standardwert. Wenn der Anspruch leer ist, wird der Standardwert verwendet. Sie können auch einen Anspruchslöser mit einem Kontextwert verwenden, z. B. die Korrelations-ID oder die IP-Adresse des Benutzers.

Antragstellername

Um die SAML Assertion NameId im Betreff als normalisierten Anspruch zu lesen, legen Sie den Anspruch PartnerClaimType auf den Wert des SPNameQualifier Attributs fest. Wenn das SPNameQualifierAttribut nicht angezeigt wird, legen Sie den Anspruch PartnerClaimType auf den Wert des NameQualifier Attributs fest.

SAML-Assertion:

<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>

Ausgabeanspruch:

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

Wenn weder die SPNameQualifier noch die NameQualifier Attribute in der SAML-Assertion vorhanden sind, legen Sie den Anspruch PartnerClaimType auf assertionSubjectName. Stellen Sie sicher, dass die NameId der erste Wert in Assertions-XML ist. Wenn Sie mehrere Assertionen definieren, wählt Azure AD B2C den Betreffwert aus der letzten Assertion aus.

Konfigurieren von SAML-Protokollbindungen

Die SAML-Anforderungen werden wie im Metadatenelement SingleSignOnService des Identitätsanbieters angegeben an den Identitätsanbieter gesendet. Die meisten Autorisierungsanforderungen der Identitätsanbieter werden direkt in der URL-Abfragezeichenfolge einer HTTP GET-Anforderung übertragen (da die Nachrichten relativ kurz sind). Informationen zum Konfigurieren der Bindungen für beide SAML-Anforderungen finden Sie in der Dokumentation ihres Identitätsanbieters.

Der folgende XML-Code ist ein Beispiel für einen Microsoft Entra-Metadaten-Single Sign-On-Dienst mit zwei Bindungen. Die HTTP-Redirect hat Vorrang vor der HTTP-POST, weil sie zuerst in den Metadaten des SAML-Identitätsanbieters aufgeführt ist.

<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>

Assertionsverbraucherdienst

Der Assertion Consumer Service (oder ACS) ist der Ort, an dem die SAML-Antworten des Identitätsanbieters gesendet und von Azure AD B2C empfangen werden. SAML-Antworten werden per HTTP POST-Bindung an Azure AD B2C übertragen. Der ACS-Speicherort verweist auf die Basisrichtlinie Ihrer vertrauenden Seite. Wenn die vertrauende Seite beispielsweise B2C_1A_signup_signin ist, ist ACS die Basisrichtlinie von B2C_1A_signup_signin, zum Beispiel B2C_1A_TrustFrameworkBase.

Der folgende XML-Code ist ein Beispiel für ein Assertionsverbraucherdienst-Element der Azure AD B2C-Richtlinienmetadaten.

<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>

Konfigurieren der SAML-Anforderungssignatur

Azure AD B2C signiert alle ausgehenden Authentifizierungsanforderungen mithilfe des kryptografischen Schlüssels SamlMessageSigning . Um die SAML-Anforderungssignatur zu deaktivieren, legen Sie die WantsSignedRequests auf false. Wenn die Metadaten auf false festgelegt sind, werden die Parameter SigAlg und Signature (Abfragezeichenfolge oder Postparameter) aus der Anforderung weggelassen.

Diese Metadaten steuern auch das AuthnRequestsSigned-Attribut , das in den Metadaten des technischen Azure AD B2C-Profils enthalten ist, das für den Identitätsanbieter freigegeben ist. Azure AD B2C signiert die Anforderung nicht, wenn der Wert von WantsSignedRequests in den Metadaten des technischen Profils auf false und in den Metadaten des Identitätsanbieters WantAuthnRequestsSigned auf false festgelegt ist oder nicht angegeben wurde.

Im folgenden Beispiel wird die Signatur aus der SAML-Anforderung entfernt.

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

Signaturalgorithmus

Azure AD B2C verwendet Sha1 zum Signieren der SAML-Anforderung. Verwenden Sie die XmlSignatureAlgorithm-Metadaten , um den zu verwendenden Algorithmus zu konfigurieren. Mögliche Werte sind Sha256, , Sha384, Sha512oder Sha1 (Standard). Diese Metadaten steuern den Wert des SigAlg-Parameters (Abfragezeichenfolge oder Postparameter) in der SAML-Anforderung. Vergewissern Sie sich, dass Sie den Signaturalgorithmus auf beiden Seiten mit demselben Wert konfigurieren. Verwenden Sie nur den Algorithmus, den Ihr Zertifikat unterstützt.

Wichtige Informationen einschließen

Wenn der Identitätsanbieter angibt, dass die Azure AD B2C-Bindung auf HTTP-POST festgelegt ist, schließt Azure AD B2C die Signatur und den Algorithmus in den Text der SAML-Anforderung ein. Sie können Microsoft Entra-ID auch so konfigurieren, dass der öffentliche Schlüssel des Zertifikats eingeschlossen wird, wenn die Bindung auf HTTP-POST gesetzt ist. Verwenden Sie die IncludeKeyInfo-Metadaten für trueoder false. Im folgenden Beispiel enthält die Microsoft Entra-ID nicht den öffentlichen Schlüssel des Zertifikats.

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

Konfigurieren der Namens-ID der SAML-Anforderung

Das SAML-Autorisierungsanforderungselement <NameID> gibt das SAML-Namensbezeichnerformat an. In diesem Abschnitt werden die Standardkonfiguration und das Anpassen des Namens-ID-Elements beschrieben.

Bevorzugter Benutzername

Während einer User Journey für die Anmeldung kann eine Anwendung der vertrauenden Seite auf bestimmte Benutzende ausgerichtet werden. Mit Azure AD B2C können Sie einen bevorzugten Benutzernamen an den SAML-Identitätsanbieter senden. Das InputClaims-Element wird verwendet, um eine NameId innerhalb des Betreffs der SAML-Autorisierungsanforderung zu senden.

Um die Antragstellernamen-ID in die Autorisierungsanforderung einzuschließen, fügen Sie das folgende <InputClaims> Element unmittelbar hinter dem <CryptographicKeys>. Der PartnerClaimType muss auf subject gesetzt werden.

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

In diesem Beispiel sendet Azure AD B2C den Wert des signInName-Anspruchs mit NameId innerhalb des Betreffs der SAML-Autorisierungsanforderung.

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

Sie können Kontextansprüche verwenden, wie {OIDC:LoginHint}, um den Anspruchswert zu setzen.

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

Namens-ID-Richtlinienformat

Standardmäßig gibt die SAML-Autorisierungsanforderung die urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified Richtlinie an. Diese Namens-ID gibt an, dass jeder vom Identitätsanbieter für den angeforderten Betreff unterstützte Bezeichnertyp verwendet werden kann.

Informationen zum Ändern dieses Verhaltens finden Sie in der Dokumentation Ihres Identitätsanbieters, um zu erfahren, welche Namens-ID-Richtlinien unterstützt werden. Fügen Sie dann die NameIdPolicyFormat Metadaten im entsprechenden Richtlinienformat hinzu. Beispiel:

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

Die folgende SAML-Autorisierungsanforderung enthält die Namens-ID-Richtlinie.

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

Erstellen neuer Konten zulassen

Wenn Sie das Namens-ID-Richtlinienformat angeben, können Sie auch die AllowCreate Eigenschaft von NameIDPolicy angeben, um anzugeben, ob der Identitätsanbieter während des Anmeldeflusses ein neues Konto erstellen darf. Eine Anleitung finden Sie in der Dokumentation Ihres Identitätsanbieters.

Azure AD B2C lässt die AllowCreate Eigenschaft standardmäßig aus. Sie können dieses Verhalten mithilfe der NameIdPolicyAllowCreate Metadaten ändern. Der Wert dieser Metadaten ist true oder false.

Im folgenden Beispiel wird veranschaulicht, wie die Eigenschaft AllowCreate von NameIDPolicy auf true gesetzt wird.

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

Im folgenden Beispiel wird eine Autorisierungsanforderung mit AllowCreate des NameIDPolicy-Elements in der Autorisierungsanforderung veranschaulicht.

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

Erzwingen der Authentifizierung

Sie können erzwingen, dass der externe SAML-IDP den Benutzer zur Authentifizierung auffordert, indem Sie die ForceAuthN Eigenschaft in der SAML-Authentifizierungsanforderung übergeben. Ihr Identitätsanbieter muss diese Eigenschaft ebenfalls unterstützen.

Die ForceAuthN Eigenschaft ist ein boolescher true oder false Wert. Standardmäßig legt Azure AD B2C den ForceAuthN-Wert auf false. Wenn die Sitzung anschließend zurückgesetzt wird (z. B. durch Verwendung des prompt=login in OIDC), wird der Wert von ForceAuthN auf true gesetzt. Wenn Sie die ForceAuthN-Metadaten auf true festlegen, wird der Wert für alle Anforderungen an den externen Identitätsanbieter erzwungen.

Das folgende Beispiel zeigt die Eigenschaft ForceAuthN, die auf true festgelegt ist:

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

Das folgende Beispiel zeigt die ForceAuthN Eigenschaft in einer Autorisierungsanforderung:

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

Anbietername

Optional können Sie das ProviderName Attribut in die SAML-Autorisierungsanforderung einschließen. Legen Sie die ProviderName Metadaten fest, um den Anbieternamen für alle Anforderungen an den externen SAML-IDP einzuschließen. Das folgende Beispiel zeigt die Eigenschaft ProviderName, die auf Contoso app festgelegt ist:

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

Das folgende Beispiel zeigt die ProviderName Eigenschaft in einer Autorisierungsanforderung:

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

Authentifizierungskontextklassenverweise einschließen

Eine SAML-Autorisierungsanforderung kann ein AuthnContext-Element enthalten, das den Kontext einer Autorisierungsanforderung angibt. Das Element kann einen Authentifizierungskontextklassenverweis enthalten, der dem SAML-Identitätsanbieter angibt, welcher Authentifizierungsmechanismus dem Benutzer präsentiert werden soll.

Um die Authentifizierungskontextklassenverweise zu konfigurieren, fügen Sie IncludeAuthnContextClassReferences-Metadaten hinzu. Geben Sie im Wert einen oder mehrere URI-Verweise an, die Authentifizierungskontextklassen identifizieren. Geben Sie mehrere URIs als durch Trennzeichen getrennte Liste an. In der Dokumentation Ihres Identitätsanbieters finden Sie Anleitungen zu den unterstützten AuthnContextClassRef-URIs .

Im folgenden Beispiel können sich Benutzer mit Benutzername und Kennwort anmelden und sich mit Benutzername und Kennwort über eine geschützte Sitzung (SSL/TLS) anmelden.

<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>

Die folgende SAML-Autorisierungsanforderung enthält die Authentifizierungskontextklassenverweise.

<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>

Einschließen von benutzerdefinierten Daten in die Autorisierungsanforderung

Sie können optional Elemente der Protokollnachrichtenerweiterung einschließen, die sowohl von Azure AD B2C als auch Ihrem Identitätsanbieter vereinbart werden. Die Erweiterung wird im XML-Format dargestellt. Sie fügen Erweiterungselemente hinzu, indem Sie XML-Daten innerhalb des CDATA-Elements <![CDATA[Your Custom XML]]>hinzufügen. Überprüfen Sie die Dokumentation Ihres Identitätsanbieters, um festzustellen, ob das Erweiterungselement unterstützt wird.

Das folgende Beispiel veranschaulicht die Verwendung von Erweiterungsdaten:

<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>

Bei der SAML-Protokoll-Nachrichtenerweiterung sieht die SAML-Antwort wie im folgenden Beispiel aus:

<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>

Anfordern signierter SAML-Antworten

Azure AD B2C erfordert, dass alle eingehenden Assertionen signiert werden. Sie können diese Anforderung entfernen, indem Sie die WantsSignedAssertions auf falsefestlegen. Der Identitätsanbieter sollte die Assertionen in diesem Fall nicht signieren, aber selbst wenn dies der Fall ist, überprüft Azure AD B2C die Signatur nicht.

Die Metadaten für WantSignedAssertions steuern das SAML-Metadaten-Flag WantAssertionsSigned, das in den Metadaten des technischen Profils von Azure AD B2C enthalten ist, das mit dem Identitätsanbieter geteilt wird.

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

Wenn Sie die Assertionsüberprüfung deaktivieren, möchten Sie möglicherweise auch die Signaturüberprüfung der Antwortnachricht deaktivieren. Legen Sie die ResponsesSigned-Metadaten auf false fest. Der Identitätsanbieter sollte die SAML-Antwortnachricht in diesem Fall nicht signieren, aber selbst wenn dies der Fall ist, überprüft Azure AD B2C die Signatur nicht.

Im folgenden Beispiel werden sowohl die Nachricht als auch die Assertionssignatur entfernt:

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

Anfordern verschlüsselter SAML-Antworten

Damit alle eingehenden Assertionen verschlüsselt werden müssen, legen Sie die Metadaten "WantsEncryptedAssertions " fest. Wenn verschlüsselung erforderlich ist, verwendet der Identitätsanbieter einen öffentlichen Schlüssel eines Verschlüsselungszertifikats in einem technischen Azure AD B2C-Profil. Azure AD B2C entschlüsselt die Antwort assertion mithilfe des privaten Teils des Verschlüsselungszertifikats.

Wenn Sie die Assertionsverschlüsselung aktivieren, müssen Sie möglicherweise auch die Überprüfung der Antwortsignatur deaktivieren (weitere Informationen finden Sie unter Erforderlicher signierter SAML-Antworten).

Wenn die Metadaten WantsEncryptedAssertions auf true festgelegt sind, umfassen die Metadaten des technischen Azure AD B2C-Profils den Abschnitt Verschlüsselung. Der Identitätsanbieter liest die Metadaten und verschlüsselt die SAML-Assertion mit dem öffentlichen Schlüssel, der in den Metadaten des technischen Profils von Azure AD B2C zur Verfügung gestellt ist.

Das folgende Beispiel zeigt den Abschnitt "Schlüsseldeskriptor" der SAML-Metadaten, die für die Verschlüsselung verwendet werden:

<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>

Um die SAML-Antwort-Assertion zu verschlüsseln:

1. Erstellen Sie einen Richtlinienschlüssel mit einem eindeutigen Bezeichner. Beispiel: B2C_1A_SAMLEncryptionCert.

2. In der CryptographicKeys-Sammlung des technischen SAML-Profils. Legen Sie die StorageReferenceId auf den Namen des Richtlinienschlüssels fest, den Sie im ersten Schritt erstellt haben. Die SamlAssertionDecryption ID gibt die Verwendung des kryptografischen Schlüssels an, um die Assertion der SAML-Antwort zu verschlüsseln und zu entschlüsseln.

   <CryptographicKeys>
           ...
     <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
   </CryptographicKeys>
   

3. Legen Sie die Metadaten des technischen Profils WantsEncryptedAssertions auf true.

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

4. Aktualisieren Sie Ihren Identitätsanbieter mit den neuen technischen Profilmetadaten von Azure AD B2C. Sie sollten den KeyDescriptor mit der auf eingestellten encryption-Eigenschaft sehen, der den öffentlichen Schlüssel Ihres Zertifikats enthält.

Aktivieren der Verwendung von Kontextansprüchen

In der Sammlung von Eingabe- und Ausgabeansprüchen können Sie Ansprüche einschließen, die nicht vom Identitätsanbieter zurückgegeben werden, solange Sie das DefaultValue Attribut festlegen. Sie können auch Kontextansprüche verwenden, um in das technische Profil aufgenommen zu werden. So verwenden Sie einen Kontextanspruch:

1. Fügen Sie dem ClaimsSchema-Element in BuildingBlocks einen Anspruchstyp hinzu.

2. Fügen Sie der Eingabe- oder Ausgabeauflistung einen Ausgabeanspruch hinzu. Im folgenden Beispiel legt der erste Anspruch den Wert des Identitätsanbieters fest. Der zweite Anspruch verwendet die Benutzer-IP-Adresse Kontextansprüche.

   <OutputClaims>
     <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" AlwaysUseDefaultValue="true" />
     <OutputClaim ClaimTypeReferenceId="IpAddress" DefaultValue="{Context:IPAddress}" AlwaysUseDefaultValue="true" />
   </OutputClaims>
   

Deaktivieren des einmaligen Abmeldens

Bei einer Anwendungsaussignierungsanforderung versucht Azure AD B2C, sich von Ihrem SAML-Identitätsanbieter abzumelden. Weitere Informationen finden Sie unter Abmelden von der Azure AD B2C-Sitzung. Um das Verhalten des einmaligen Abmeldens zu deaktivieren, legen Sie die Metadaten SingleLogoutEnabled auf false fest.

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

Debuggen des SAML-Protokolls

Um den Partnerverbund mit einem SAML-Identitätsanbieter zu konfigurieren und zu debuggen, können Sie eine Browsererweiterung für das SAML-Protokoll verwenden, z. B. die SAML DevTools-Erweiterung für Chrome, SAML-Tracer für Firefox, Microsoft Edge oder Internet Explorer-Entwicklertools.

Mithilfe dieser Tools können Sie die Integration zwischen Azure AD B2C und Ihrem SAML-Identitätsanbieter überprüfen. Beispiel:

• Überprüfen Sie, ob die SAML-Anforderung eine Signatur enthält, und bestimmen Sie, welcher Algorithmus für die Anmeldung bei der Autorisierungsanforderung verwendet wird.
• Rufen Sie die Ansprüche (Assertionen) unter dem Abschnitt AttributeStatement ab.
• Überprüfen Sie, ob der Identitätsanbieter eine Fehlermeldung zurückgibt.
• Überprüfen Sie, ob der Assertionsabschnitt verschlüsselt ist.

SAML-Anforderungs- und Antwortbeispiele

Security Assertion Markup Language (SAML) ist ein offener Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen einem Identitätsanbieter und einem Dienstanbieter. Wenn Azure AD B2C mit einem SAML-Identitätsanbieter föderiert, fungiert es als Dienstanbieter, der eine SAML-Anforderung an den SAML-Identitätsanbieter initiiert und auf eine SAML-Antwort wartet.

Eine erfolgreiche SAML-Antwort enthält Sicherheits-assertionen, die von den externen SAML-Identitätsanbietern erstellt wurden. Azure AD B2C analysiert und ordnet die Assertionen Ansprüchen zu.

Autorisierungsanforderung

Um eine Benutzerauthentifizierung anzufordern, sendet Azure AD B2C ein AuthnRequest Element an den externen SAML-Identitätsanbieter. Ein Beispiel für SAML 2.0-AuthnRequest könnte wie im folgenden Beispiel aussehen:

<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>

Antwort

Wenn die angeforderte Anmeldung erfolgreich abgeschlossen wurde, sendet der externe SAML-Identitätsanbieter eine Antwort auf den Azure AD B2C Assertion Consumer Service-Endpunkt . Eine Antwort auf einen erfolgreichen Anmeldeversuch sieht wie im folgenden Beispiel aus:

<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>

Abmeldeanforderung

Bei einer Anwendungsaussignierungsanforderung versucht Azure AD B2C, sich von Ihrem SAML-Identitätsanbieter abzumelden. Azure AD B2C sendet eine LogoutRequest Nachricht an den externen IDP, um anzugeben, dass eine Sitzung beendet wurde. Der folgende Auszug zeigt ein Beispielelement LogoutRequest .

Der Wert des Element NameID entspricht dem NameID der benutzenden Person, die abgemeldet wird. Das Element SessionIndex entspricht dem Attribut SessionIndex der AuthnStatement in der SAML-Antwort für die Anmeldung.

<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>

Nächste Schritte

• Erfahren Sie, wie Sie Probleme mit Ihren benutzerdefinierten Richtlinien mithilfe von Application Insights diagnostizieren.