Udostępnij za pośrednictwem

Konfigurowanie opcji dostawcy tożsamości SAML za pomocą usługi Azure Active Directory B2C

  • Artykuł

Usługa Azure Active Directory B2C (Azure AD B2C) obsługuje federację z dostawcami tożsamości SAML 2.0. W tym artykule opisano sposób analizowania asercji zabezpieczeń oraz opcji konfiguracji, które są dostępne podczas włączania logowania za pomocą dostawcy tożsamości SAML.

Przed rozpoczęciem użyj selektora Wybierz typ zasad , aby wybrać typ konfigurowanych zasad. Usługa Azure Active Directory B2C oferuje dwie metody definiowania sposobu interakcji użytkowników z aplikacjami: za pomocą wstępnie zdefiniowanych przepływów użytkownika lub w pełni konfigurowalnych zasad niestandardowych. Kroki wymagane w tym artykule są inne dla każdej metody.

Ta funkcja jest dostępna tylko dla zasad niestandardowych. W przypadku kroków konfiguracji wybierz pozycję Zasady niestandardowe w poprzednim selektorze.

Mapowanie oświadczeń

Element OutputClaims zawiera listę oświadczeń zwróconych przez dostawcę tożsamości SAML. Musisz zamapować nazwę oświadczenia zdefiniowanego w zasadach na nazwę zdefiniowaną w dostawcy tożsamości. Sprawdź dostawcę tożsamości, aby uzyskać listę oświadczeń (asercji). Możesz również sprawdzić zawartość odpowiedzi SAML zwracanej przez dostawcę tożsamości. Aby uzyskać więcej informacji, zobacz Debugowanie komunikatów SAML. Aby dodać oświadczenie, najpierw zdefiniuj oświadczenie, a następnie dodaj oświadczenie do kolekcji oświadczeń wyjściowych.

Można również uwzględnić oświadczenia, które nie są zwracane przez dostawcę tożsamości, o ile ustawisz DefaultValue atrybut. Wartość domyślna może być statyczna lub dynamiczna przy użyciu oświadczeń kontekstu.

Element oświadczenia wyjściowego zawiera następujące atrybuty:

  • ClaimTypeReferenceId jest odwołaniem do typu oświadczenia.
  • PartnerClaimType jest nazwą właściwości, która jest wyświetlana asercji SAML.
  • DefaultValue to wstępnie zdefiniowana wartość domyślna. Jeśli oświadczenie jest puste, zostanie użyta wartość domyślna. Można również użyć funkcji rozpoznawania oświadczeń z wartością kontekstową, taką jak identyfikator korelacji lub adres IP użytkownika.

Nazwa podmiotu

Aby odczytać identyfikator NameId asercji SAML w temacie jako znormalizowane oświadczenie, ustaw wartość atrybutu PartnerClaimType oświadczenia SPNameQualifier . SPNameQualifierJeśli atrybut nie jest prezentowany, ustaw wartość atrybutu PartnerClaimType oświadczeniaNameQualifier.

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

Oświadczenie wyjściowe:

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

Jeśli oba SPNameQualifier atrybuty lub NameQualifier nie są prezentowane w asercji SAML, ustaw dla oświadczenia PartnerClaimType wartość assertionSubjectName. Upewnij się, że parametr NameId jest pierwszą wartością w pliku XML asercji. Podczas definiowania więcej niż jednego potwierdzenia Azure AD B2C wybiera wartość podmiotu z ostatniej asercji.

Konfigurowanie powiązań protokołu SAML

Żądania SAML są wysyłane do dostawcy tożsamości, jak określono w elemecie metadanych SingleSignOnService dostawcy tożsamości. Większość żądań autoryzacji dostawców tożsamości jest przenoszona bezpośrednio w ciągu zapytania ADRESU URL żądania HTTP GET (ponieważ komunikaty są stosunkowo krótkie). Zapoznaj się z dokumentacją dostawcy tożsamości, aby dowiedzieć się, jak skonfigurować powiązania dla obu żądań SAML.

Poniższy kod XML to przykład usługi logowania jednokrotnego metadanych Microsoft Entra z dwoma powiązaniami. Element HTTP-Redirect ma pierwszeństwo przed elementem HTTP-POST , ponieważ jest wyświetlany jako pierwszy w metadanych dostawcy tożsamości 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>

Usługa konsumenta asercji

Usługa Assertion Consumer Service (lub ACS) to miejsce, w którym odpowiedzi SAML dostawcy tożsamości są wysyłane i odbierane przez Azure AD B2C. Odpowiedzi SAML są przesyłane do Azure AD B2C za pośrednictwem powiązania HTTP POST. Lokalizacja ACS wskazuje podstawowe zasady jednostki uzależnionej. Jeśli na przykład zasady jednostki uzależnionej są B2C_1A_signup_signin, usługa ACS jest podstawowymi zasadami B2C_1A_signup_signin, takimi jak B2C_1A_TrustFrameworkBase.

Poniższy kod XML to przykład elementu usługi konsumenta asercji metadanych zasad B2C 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>

Konfigurowanie podpisu żądania SAML

Azure AD B2C podpisuje wszystkie wychodzące żądania uwierzytelniania przy użyciu klucza kryptograficznego SamlMessageSigning. Aby wyłączyć podpis żądania SAML, ustaw właściwość WantsSignedRequests na false. Jeśli metadane są ustawione na falsewartość , parametry SigAlg i Signature (ciąg zapytania lub parametr post) zostaną pominięte w żądaniu.

Te metadane steruje również atrybutem AuthnRequestsSigned, który jest dołączony do metadanych profilu technicznego Azure AD B2C, który jest udostępniany dostawcy tożsamości. Azure AD B2C nie podpisuje żądania, jeśli wartość WantsSignedRequests w metadanych profilu technicznego jest ustawiona na false , a metadane dostawcy tożsamości WantAuthnRequestsSigned są ustawione na false wartość lub nie są określone.

Poniższy przykład usuwa podpis z żądania SAML.

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

Algorytm podpisu

Azure AD B2C używa Sha1 do podpisania żądania SAML. Użyj metadanych XmlSignatureAlgorithm , aby skonfigurować algorytm do użycia. Możliwe wartości to Sha256, Sha384, Sha512lub Sha1 (wartość domyślna). Te metadane steruje wartością parametru SigAlg (ciągu zapytania lub parametru post) w żądaniu SAML. Upewnij się, że algorytm podpisu jest konfigurowany po obu stronach o tej samej wartości. Użyj tylko algorytmu obsługiwanego przez certyfikat.

Dołącz informacje o kluczu

Gdy dostawca tożsamości wskazuje, że Azure AD powiązanie B2C jest ustawione na HTTP-POSTwartość , Azure AD B2C zawiera podpis i algorytm w treści żądania SAML. Można również skonfigurować identyfikator Microsoft Entra, aby uwzględnić klucz publiczny certyfikatu, gdy powiązanie jest ustawione na HTTP-POSTwartość . Użyj metadanych IncludeKeyInfo do true, lub false. W poniższym przykładzie identyfikator Microsoft Entra nie zawiera klucza publicznego certyfikatu.

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

Konfigurowanie identyfikatora nazwy żądania SAML

Element żądania <NameID> autoryzacji SAML wskazuje format identyfikatora nazwy SAML. W tej sekcji opisano konfigurację domyślną i sposób dostosowywania elementu identyfikatora nazwy.

Preferowana nazwa użytkownika

Podczas podróży użytkownika logowania aplikacja jednostki uzależnionej może być skierowana do określonego użytkownika. Azure AD B2C umożliwia wysyłanie preferowanej nazwy użytkownika do dostawcy tożsamości SAML. Element InputClaims służy do wysyłania identyfikatora NameId w ramach podmiotu żądania autoryzacji SAML.

Aby uwzględnić identyfikator nazwy podmiotu w żądaniu autoryzacji, dodaj następujący <InputClaims> element bezpośrednio po elemecie <CryptographicKeys>. Właściwość PartnerClaimType musi być ustawiona na subjectwartość .

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

W tym przykładzie Azure AD B2C wysyła wartość oświadczenia signInName o identyfikatorze NameId w temacie żądania autoryzacji SAML.

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

Możesz użyć oświadczeń kontekstowych, takich jak {OIDC:LoginHint} wypełnianie wartości oświadczenia.

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

Format zasad identyfikatora nazwy

Domyślnie żądanie autoryzacji SAML określa urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified zasady. Ten identyfikator nazwy wskazuje, że można użyć dowolnego typu identyfikatora obsługiwanego przez dostawcę tożsamości dla żądanego podmiotu.

Aby zmienić to zachowanie, zapoznaj się z dokumentacją dostawcy tożsamości, aby uzyskać wskazówki dotyczące obsługiwanych zasad identyfikatorów nazw. Następnie dodaj NameIdPolicyFormat metadane w odpowiednim formacie zasad. Na przykład:

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

Następujące żądanie autoryzacji SAML zawiera zasady identyfikatora nazwy.

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

Zezwalaj na tworzenie nowych kont

Jeśli określisz format zasad Identyfikator nazwy, możesz również określić AllowCreate właściwość NameIDPolicy , aby wskazać, czy dostawca tożsamości może utworzyć nowe konto podczas przepływu logowania. Aby uzyskać wskazówki, zapoznaj się z dokumentacją dostawcy tożsamości.

Azure AD B2C domyślnie pomija AllowCreate właściwość. To zachowanie można zmienić przy użyciu NameIdPolicyAllowCreate metadanych. Wartość tych metadanych to true lub false.

W poniższym przykładzie pokazano, jak ustawić AllowCreate właściwość NameIDPolicy na truewartość .

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

W poniższym przykładzie pokazano żądanie autoryzacji z elementem AllowCreate elementu NameIDPolicy w żądaniu autoryzacji.

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

Wymuszanie uwierzytelniania

Możesz wymusić na zewnętrznym dostawcy tożsamości SAML monitowanie użytkownika o uwierzytelnienie, przekazując ForceAuthN właściwość w żądaniu uwierzytelniania SAML. Dostawca tożsamości musi również obsługiwać tę właściwość.

Właściwość ForceAuthN jest wartością logiczną true lub false wartością. Domyślnie Azure AD B2C ustawia wartość ForceAuthN na falsewartość . Jeśli sesja zostanie zresetowana (na przykład przy użyciu w identyfikatorze prompt=login OIDC), wartość jest ustawiona ForceAuthN na truewartość . ForceAuthN Ustawienie metadanych wymusza true wartość dla wszystkich żądań do zewnętrznego dostawcy tożsamości.

W poniższym przykładzie pokazano właściwość ustawioną ForceAuthN na true:

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

Poniższy przykład przedstawia ForceAuthN właściwość w żądaniu autoryzacji:

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

Nazwa dostawcy

Opcjonalnie możesz uwzględnić ProviderName atrybut w żądaniu autoryzacji SAML. Ustaw metadane tak ProviderName , aby zawierały nazwę dostawcy dla wszystkich żądań do zewnętrznego dostawcy tożsamości SAML. W poniższym przykładzie pokazano właściwość ustawioną ProviderName na Contoso app:

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

Poniższy przykład przedstawia ProviderName właściwość w żądaniu autoryzacji:

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

Dołączanie odwołań do klas kontekstu uwierzytelniania

Żądanie autoryzacji SAML może zawierać element AuthnContext , który określa kontekst żądania autoryzacji. Element może zawierać odwołanie do klasy kontekstu uwierzytelniania, które informuje dostawcę tożsamości SAML, który mechanizm uwierzytelniania ma być prezentowany użytkownikowi.

Aby skonfigurować odwołania do klasy kontekstu uwierzytelniania, dodaj metadane IncludeAuthnContextClassReferences . W wartości określ co najmniej jedno odwołanie do identyfikatora URI identyfikujące klasy kontekstu uwierzytelniania. Określ wiele identyfikatorów URI jako listę rozdzielaną przecinkami. Zapoznaj się z dokumentacją dostawcy tożsamości, aby uzyskać wskazówki dotyczące obsługiwanych identyfikatorów URI AuthnContextClassRef .

Poniższy przykład umożliwia użytkownikom logowanie się przy użyciu nazwy użytkownika i hasła oraz logowanie się przy użyciu nazwy użytkownika i hasła za pośrednictwem sesji chronionej (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>

Następujące żądanie autoryzacji SAML zawiera odwołania do klasy kontekstu uwierzytelniania.

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

Uwzględnianie danych niestandardowych w żądaniu autoryzacji

Opcjonalnie możesz uwzględnić elementy rozszerzenia komunikatów protokołu, które są uzgodnione zarówno przez Azure AD B2C, jak i dostawcę tożsamości. Rozszerzenie jest prezentowane w formacie XML. Elementy rozszerzenia są uwzględniane przez dodanie danych XML wewnątrz elementu <![CDATA[Your Custom XML]]>CDATA . Sprawdź dokumentację dostawcy tożsamości, aby sprawdzić, czy element rozszerzeń jest obsługiwany.

Poniższy przykład ilustruje użycie danych rozszerzenia:

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

Uwaga

Zgodnie ze specyfikacją JĘZYKA SAML dane rozszerzenia muszą być kwalifikowanym plikiem XML przestrzeni nazw (na przykład "urn:ext:custom" pokazanym w przykładzie) i nie mogą być jedną z przestrzeni nazw specyficznych dla języka SAML.

W przypadku rozszerzenia komunikatów protokołu SAML odpowiedź SAML wygląda podobnie do następującego przykładu:

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

Wymagaj podpisanych odpowiedzi SAML

Azure AD B2C wymaga podpisania wszystkich asercji przychodzących. To wymaganie można usunąć, ustawiając wartość WantsSignedAssertions na false. Dostawca tożsamości nie powinien podpisywać asercji w tym przypadku, ale nawet jeśli tak, Azure AD B2C nie weryfikuje podpisu.

Metadane WantsSignedAssertions steruje flagą metadanych SAML WantAssertionsSigned, która jest uwzględniona w metadanych profilu technicznego usługi Azure AD B2C, który jest udostępniany dostawcy tożsamości.

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

Jeśli wyłączysz walidację asercji, możesz również wyłączyć walidację podpisu komunikatu odpowiedzi. Ustaw wartość OdpowiedźPodpisane metadane na false. Dostawca tożsamości nie powinien w tym przypadku podpisać komunikatu odpowiedzi SAML, ale nawet jeśli tak, Azure AD B2C nie weryfikuje podpisu.

Poniższy przykład usuwa zarówno komunikat, jak i podpis asercji:

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

Wymagaj zaszyfrowanych odpowiedzi SAML

Aby wymagać szyfrowania wszystkich asercji przychodzących, ustaw metadane WantsEncryptedAssertions . Jeśli szyfrowanie jest wymagane, dostawca tożsamości używa klucza publicznego certyfikatu szyfrowania w profilu technicznym usługi Azure AD B2C. Azure AD B2C odszyfrowuje potwierdzenie odpowiedzi przy użyciu prywatnej części certyfikatu szyfrowania.

Jeśli włączysz szyfrowanie asercji, może być również konieczne wyłączenie weryfikacji podpisu odpowiedzi (aby uzyskać więcej informacji, zobacz Wymagaj podpisanych odpowiedzi SAML.

Gdy metadane WantsEncryptedAssertions są ustawione na truewartość , metadane profilu technicznego usługi Azure AD B2C zawierają sekcję szyfrowania. Dostawca tożsamości odczytuje metadane i szyfruje potwierdzenie odpowiedzi SAML przy użyciu klucza publicznego podanego w metadanych profilu technicznego usługi Azure AD B2C.

W poniższym przykładzie przedstawiono sekcję Deskryptor kluczy metadanych JĘZYKA SAML używanych do szyfrowania:

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

Aby zaszyfrować asercję odpowiedzi SAML:

  1. Utwórz klucz zasad z unikatowym identyfikatorem. Na przykład B2C_1A_SAMLEncryptionCert.

  2. W kolekcji CryptographicKeys profilu technicznego SAML. Ustaw wartość StorageReferenceId na nazwę klucza zasad utworzonego w pierwszym kroku. Identyfikator SamlAssertionDecryption wskazuje użycie klucza kryptograficznego do szyfrowania i odszyfrowywania potwierdzenia odpowiedzi SAML.

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

  3. Ustaw metadane profilu technicznego WantsEncryptedAssertions na truewartość .

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

  4. Zaktualizuj dostawcę tożsamości przy użyciu nowych metadanych profilu technicznego usługi Azure AD B2C. Powinna zostać wyświetlona właściwość KeyDescriptor z właściwością use ustawioną na encryption wartość zawierającą klucz publiczny certyfikatu.

Włączanie korzystania z oświadczeń kontekstowych

W kolekcji oświadczeń wejściowych i wyjściowych można uwzględnić oświadczenia, które nie są zwracane przez dostawcę tożsamości, o ile atrybut został DefaultValue ustawiony. Można również użyć oświadczeń kontekstowych , aby uwzględnić je w profilu technicznym. Aby użyć oświadczenia kontekstu:

  1. Dodaj typ oświadczenia do elementu ClaimsSchema w bloku BuildingBlocks.

  2. Dodaj oświadczenie wyjściowe do kolekcji wejściowej lub wyjściowej. W poniższym przykładzie pierwsze oświadczenie ustawia wartość dostawcy tożsamości. Drugie oświadczenie używa oświadczeń kontekstu adresu IP użytkownika.

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

Wyłączanie wylogowania jednokrotnego

Po żądaniu wylogowania aplikacji Azure AD B2C próbuje wylogować się z dostawcy tożsamości SAML. Aby uzyskać więcej informacji, zobacz Azure AD wylogowywanie sesji B2C. Aby wyłączyć zachowanie wylogowania jednokrotnego, ustaw metadane SingleLogoutEnabled na falsewartość .

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

Debugowanie protokołu SAML

Aby ułatwić konfigurowanie i debugowanie federacji za pomocą dostawcy tożsamości SAML, można użyć rozszerzenia przeglądarki dla protokołu SAML, takiego jak rozszerzenie SAML DevTools dla programu Chrome, narzędzie śledzenia SAML dla programu FireFox lub przeglądarki Microsoft Edge lub Narzędzia programistyczne IE.

Za pomocą tych narzędzi możesz sprawdzić integrację między usługą Azure AD B2C i dostawcą tożsamości SAML. Na przykład:

  • Sprawdź, czy żądanie SAML zawiera podpis i określ, jaki algorytm jest używany do logowania się w żądaniu autoryzacji.
  • Pobierz oświadczenia (asercji) w AttributeStatement sekcji .
  • Sprawdź, czy dostawca tożsamości zwraca komunikat o błędzie.
  • Sprawdź, czy sekcja asercji jest zaszyfrowana.

Przykłady żądań i odpowiedzi SAML

SAML (Security Assertion Markup Language) to otwarty standard wymiany danych uwierzytelniania i autoryzacji między dostawcą tożsamości a dostawcą usług. Gdy Azure AD B2C sfederuje się z dostawcą tożsamości SAML, działa jako dostawca usług inicjujący żądanie SAML do dostawcy tożsamości SAML i czekając na odpowiedź SAML.

Odpowiedź SAML z informacją o powodzeniu zawiera potwierdzenia zabezpieczeń, które są instrukcjami wykonanymi przez zewnętrznych dostawców tożsamości SAML. Azure AD analizy B2C i mapuje asercji na oświadczenia.

Żądanie autoryzacji

Aby zażądać uwierzytelnienia użytkownika, Azure AD B2C wysyła AuthnRequest element do zewnętrznego dostawcy tożsamości SAML. Przykładowy kod SAML 2.0 AuthnRequest może wyglądać podobnie do następującego przykładu:

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

Reakcja

Po pomyślnym zakończeniu żądanego logowania zewnętrzny dostawca tożsamości SAML publikuje odpowiedź na punkt końcowy usługi konsumenta asercji Azure AD B2C. Odpowiedź na pomyślną próbę logowania wygląda następująco:

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

Żądanie wylogowania

Po żądaniu wylogowania aplikacji Azure AD B2C próbuje wylogować się z dostawcy tożsamości SAML. Azure AD B2C wysyła LogoutRequest komunikat do zewnętrznego dostawcy tożsamości, aby wskazać, że sesja została zakończona. Poniższy fragment przedstawia przykładowy LogoutRequest element.

Wartość NameID elementu odpowiada NameID wylogowaniu użytkownika. Element SessionIndex pasuje do SessionIndex atrybutu AuthnStatement w odpowiedzi SAML logowania.

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

Następne kroki

  • Dowiedz się, jak diagnozować problemy z zasadami niestandardowymi przy użyciu usługi Application Insights.