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

Ta funkcja jest dostępna tylko dla zasad niestandardowych. Aby uzyskać instrukcje 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 mapować nazwę żądania zdefiniowaną w polityce do nazwy zdefiniowanej przez dostawcę 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 to nazwa właściwości, która pojawia się w 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ć asercję SAML NameId w elemencie Subject jako znormalizowane roszczenie, ustaw atrybut oświadczenia PartnerClaimType na wartość SPNameQualifier. Jeśli atrybut SPNameQualifier nie jest przedstawiony, ustaw oświadczenie PartnerClaimType na wartość atrybutu NameQualifier.

Asercja 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 żaden z atrybutów SPNameQualifier lub NameQualifier nie jest obecny w asercji SAML, ustaw dla oświadczenia PartnerClaimType wartość assertionSubjectName. Upewnij się, że NameId jest pierwszą wartością w asercji XML. Podczas definiowania więcej niż jednej asercji usługa 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ń autoryzacyjnych od dostawców tożsamości jest przenoszona bezpośrednio w parametrach 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 jednokrotnego logowania metadanych firmy 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 obsługi asercji

Usługa Assertion Consumer Service (lub ACS) to miejsce, w którym są wysyłane odpowiedzi SAML dostawcy tożsamości i odbierane przez usługę Azure AD B2C. Odpowiedzi SAML są przesyłane do usługi Azure AD B2C za pośrednictwem powiązania HTTP POST. Lokalizacja usługi ACS wskazuje na podstawową politykę jednostki polegającej. 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 odbiorcy asercji metadanych zasad usługi 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>

Skonfiguruj podpis żądania SAML

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

Te metadane kontrolują również atrybut AuthnRequestsSigned , który jest dołączony do metadanych profilu technicznego usługi Azure AD B2C udostępnionego dostawcy tożsamości. Usługa Azure AD B2C nie podpisuje żądania, jeśli wartość Polecenia WantsSignedRequests w metadanych profilu technicznego jest ustawiona na wartość , a metadane dostawcy tożsamości false 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

Usługa 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, , Sha384Sha512lub 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 został skonfigurowany po obu stronach o tej samej wartości. Użyj tylko algorytmu obsługiwanego przez certyfikat.

Uwzględnij kluczowe informacje

Gdy dostawca tożsamości wskazuje, że powiązanie usługi Azure AD B2C jest ustawione na HTTP-POSTwartość , usługa Azure AD B2C zawiera podpis i algorytm w treści żądania SAML. Można również skonfigurować Microsoft Entra ID, aby uwzględnić klucz publiczny certyfikatu, gdy powiązanie ma wartość HTTP-POST. Użyj metadanych IncludeKeyInfo do true, lub false. W poniższym przykładzie identyfikator Entra firmy Microsoft 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. Usługa 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 temacie żądania autoryzacji SAML.

Aby dołączyć identyfikator nazwy podmiotu (ID) w żądaniu autoryzacji, dodaj następujący element <InputClaims> bezpośrednio po <CryptographicKeys>. Wartość PartnerClaimType musi być ustawiona na wartość subject.

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

W tym przykładzie usługa Azure AD B2C wysyła wartość oświadczenia signInName o identyfikatorze NameId w obszarze Podmiot żą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}, aby wypełnić wartość 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 metadane NameIdPolicyFormat do właściwego formatu polityki. 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 politykę 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 identyfikatora 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.

Usługa 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 true.

<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 atrybutem AllowCreate dla 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 usługi IdP SAML zażądanie uwierzytelnienia użytkownika, przekazując właściwość ForceAuthN w żądaniu uwierzytelnienia 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. Domyślnie usługa Azure AD B2C ustawia wartość ForceAuthN na false. Jeśli sesja zostanie zresetowana (na przykład poprzez użycie prompt=login w OIDC), wartość ForceAuthN jest ustawiona na true. Ustawienie metadanych ForceAuthN na true wymusza tę wartość dla wszystkich żądań do zewnętrznego dostawcy usług tożsamości.

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

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

Poniższy przykład przedstawia ForceAuthN atrybut w żądaniu autoryzacji.

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

Nazwa dostawcy

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

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

Poniższy przykład przedstawia ProviderName atrybut w żądaniu autoryzacji.

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

Dołączanie odwołań do klas kontekstowych 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 przedstawia użytkownikowi.

Aby skonfigurować odwołania do klasy kontekstu uwierzytelniania, dodaj metadane IncludeAuthnContextClassReferences . W wartości określ jeden lub więcej identyfikatorów URI identyfikujących klasy kontekstu uwierzytelniania. Określ wiele identyfikatorów URI jako listę rozdzielaną przecinkami. Zapoznaj się z dokumentacją dostawcy tożsamości, aby znaleźć 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ą uzgadniane zarówno przez usługę 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 <![CDATA[Your Custom XML]]>. 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>

W przypadku rozszerzenia komunikatów protokołu SAML odpowiedź SAML wygląda jak w poniższym przykładzie:

<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

Usługa 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, usługa Azure AD B2C nie weryfikuje podpisu.

Metadane WantsSignedAssertions steruje flagą metadanych SAML WantAssertionsSigned, która jest zawarta w metadanych profilu technicznego usługi Azure AD B2C udostępnionego 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ść metadanych OdpowiedziPodpisane na false. Dostawca tożsamości nie powinien w tym przypadku podpisać komunikatu odpowiedzi SAML, ale nawet jeśli tak, usługa 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>

Wymaganie 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. Usługa Azure AD B2C odszyfrowuje asercję 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 dla metadanych WantsEncryptedAssertions ustawiona jest wartość true, to w metadanych profilu technicznego usługi Azure AD B2C znajduje się sekcja szyfrowania. Dostawca tożsamości odczytuje metadane i szyfruje asercję odpowiedzi SAML przy użyciu klucza publicznego podanego w metadanych profilu technicznego usługi Azure AD B2C.

W poniższym przykładzie przedstawiono sekcję Deskryptora klucza w metadanych 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 Skróty kryptograficzne 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 true.

   <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. Powinien zostać wyświetlony KeyDescriptor z ustawioną na use właściwością, zawierającą encryption klucz publiczny Twojego certyfikatu.

Włącz używanie oświadczeń kontekstowych

W zakresie oświadczeń wejściowych i wyjściowych można uwzględnić oświadczenia, które nie są przekazywane przez dostawcę tożsamości, pod warunkiem ustawienia atrybutu DefaultValue. Możesz również użyć oświadczeń kontekstowych , aby uwzględnić je w profilu technicznym. Aby użyć kontekstowego roszczenia:

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

2. Dodaj atrybut wyjściowy do kolekcji danych wejściowych lub wyjściowych. W poniższym przykładzie pierwsze roszczenie ustala wartość dostawcy tożsamości. Drugie roszczenie używa adresu IP użytkownika oświadczeń kontekstu.

   <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 usługa Azure AD B2C próbuje wylogować się z dostawcy tożsamości SAML. Aby uzyskać więcej informacji, zobacz wylogowywanie sesji usługi Azure AD B2C. Aby wyłączyć zachowanie wylogowania jednokrotnego, ustaw metadane SingleLogoutEnabled na wartość false.

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

Debugowanie protokołu SAML

Aby ułatwić konfigurowanie i debugowanie federacji przy użyciu 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ędzia SAML-tracer dla przeglądarki Firefox lub Microsoft Edge lub narzędzi deweloperskich programu Internet Explorer.

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

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

Przykłady żądań i odpowiedzi SAML

Security Assertion Markup Language (SAML) to otwarty standard wymiany danych uwierzytelniania i autoryzacji między dostawcą tożsamości a dostawcą usług. Gdy usługa 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. Usługa Azure AD B2C analizuje i mapuje asercji na oświadczenia.

Żądanie autoryzacji

Aby zażądać uwierzytelniania użytkownika, usługa Azure AD B2C wysyła AuthnRequest element do zewnętrznego dostawcy tożsamości SAML. Przykładowy AuthnRequest SAML 2.0 może wyglądać następująco:

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

Odpowiedź

Po pomyślnym zakończeniu żądanego logowania zewnętrzny dostawca tożsamości SAML przesyła odpowiedź na punkt końcowy usługi konsumenta asercji usługi 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 usługa Azure AD B2C próbuje wylogować się z dostawcy tożsamości SAML. Usługa 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ść elementu NameID pasuje do NameID atrybutu użytkownika, który jest wylogowywany. Element SessionIndex odpowiada SessionIndex atrybutowi 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>

Dalsze kroki

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