Rejestrowanie aplikacji SAML w usłudze Azure AD B2C

Z tego artykułu dowiesz się, jak połączyć aplikacje języka SAML (Service Markup Language) z usługą Azure Active Directory B2C (Azure AD B2C) na potrzeby uwierzytelniania.

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żytkowników lub w pełni konfigurowalnych zasad niestandardowych. Kroki wymagane w tym artykule są różne dla każdej metody.

Ta funkcja jest dostępna tylko dla zasad niestandardowych. Aby uzyskać instrukcje konfiguracji, wybierz pozycję Zasady niestandardowe w poprzednim selektorze.

Omówienie

Organizacje korzystające z usługi Azure AD B2C jako rozwiązania do zarządzania tożsamościami klientów i dostępem mogą wymagać integracji z aplikacjami uwierzytelnianymi przy użyciu protokołu SAML. Na poniższym diagramie pokazano, jak usługa Azure AD B2C służy jako dostawca tożsamości (IdP), aby osiągnąć logowanie jednokrotne (SSO) przy użyciu aplikacji opartych na protokole SAML.

1. Aplikacja tworzy żądanie SAML AuthN wysyłane do punktu końcowego logowania SAML dla usługi Azure AD B2C.
2. Użytkownik może użyć konta lokalnego usługi Azure AD B2C lub innego dostawcy tożsamości federacyjnej (jeśli skonfigurowano) do uwierzytelniania.
3. Jeśli użytkownik zaloguje się przy użyciu dostawcy tożsamości federacyjnej, odpowiedź tokenu zostanie wysłana do usługi Azure AD B2C.
4. Usługa Azure AD B2C generuje asercję SAML i wysyła ją do aplikacji.

Obejrzyj ten film wideo, aby dowiedzieć się, jak zintegrować aplikacje SAML z usługą Azure AD B2C.

Wymagania wstępne

W przypadku scenariusza w tym artykule potrzebne są następujące elementy:

• Zasady niestandardowe SocialAndLocalAccounts z niestandardowego pakietu startowego zasad. Wykonaj kroki opisane w artykule Wprowadzenie do zasad niestandardowych w usłudze Azure AD B2C.
• Podstawowa wiedza na temat protokołu SAML i znajomość implementacji JĘZYKA SAML aplikacji.
• Aplikacja internetowa skonfigurowana jako aplikacja SAML. Musi mieć możliwość wysyłania żądań saml AuthN i odbierania, dekodowania i weryfikowania odpowiedzi SAML z usługi Azure AD B2C. Aplikacja SAML jest również nazywana aplikacją lub dostawcą usług jednostki uzależnionej.
• Publicznie dostępny punkt końcowy metadanych SAML lub dokument XML aplikacji SAML.
• Dzierżawa usługi Azure AD B2C.

Jeśli nie masz jeszcze aplikacji SAML i skojarzonego punktu końcowego metadanych, możesz użyć aplikacji testowej SAML, którą udostępniliśmy do testowania.

Ważne

Punkty końcowe muszą być zgodne z wymaganiami dotyczącymi zabezpieczeń usługi Azure AD B2C. Starsze wersje protokołu TLS i szyfry są przestarzałe. Aby uzyskać więcej informacji, zobacz Wymagania dotyczące protokołu TLS i pakietu szyfrowania usługi Azure AD B2C.

Konfigurowanie certyfikatów

Aby utworzyć relację zaufania między aplikacją a usługą Azure AD B2C, obie usługi muszą mieć możliwość tworzenia i weryfikowania podpisów nawzajem. Skonfiguruj certyfikaty X509 w aplikacji i w usłudze Azure AD B2C.

Certyfikaty aplikacji

Użycie	Wymagania	opis
Podpisywanie żądań SAML	Nie.	Certyfikat z kluczem prywatnym przechowywanym w aplikacji internetowej. Aplikacja używa certyfikatu do podpisywania żądań SAML wysyłanych do usługi Azure AD B2C. Aplikacja internetowa musi uwidocznić klucz publiczny za pośrednictwem punktu końcowego metadanych JĘZYKA SAML. Usługa Azure AD B2C weryfikuje podpis żądania SAML przy użyciu klucza publicznego z metadanych aplikacji.
Szyfrowanie asercji SAML	Nie.	Certyfikat z kluczem prywatnym przechowywanym w aplikacji internetowej. Aplikacja internetowa musi uwidocznić klucz publiczny za pośrednictwem punktu końcowego metadanych JĘZYKA SAML. Usługa Azure AD B2C może szyfrować asercji w aplikacji przy użyciu klucza publicznego. Aplikacja używa klucza prywatnego do odszyfrowania asercji.

Certyfikaty usługi Azure AD B2C

Użycie	Wymagania	opis
Podpisywanie odpowiedzi SAML	Tak	Certyfikat z kluczem prywatnym przechowywanym w usłudze Azure AD B2C. Usługa Azure AD B2C używa tego certyfikatu do podpisania odpowiedzi SAML wysłanej do aplikacji. Aplikacja odczytuje klucz publiczny metadanych w usłudze Azure AD B2C, aby zweryfikować podpis odpowiedzi SAML.
Podpisywanie asercji SAML	Tak	Certyfikat z kluczem prywatnym przechowywanym w usłudze Azure AD B2C. Usługa Azure AD B2C używa tego certyfikatu do podpisania <saml:Assertion> części odpowiedzi SAML.

W środowisku produkcyjnym zalecamy używanie certyfikatów wystawionych przez publiczny urząd certyfikacji. Można jednak również wykonać tę procedurę przy użyciu certyfikatów z podpisem własnym.

Tworzenie klucza zasad

Aby mieć relację zaufania między aplikacją a usługą Azure AD B2C, utwórz certyfikat podpisywania dla odpowiedzi SAML. Usługa Azure AD B2C używa tego certyfikatu do podpisania odpowiedzi SAML wysłanej do aplikacji. Aplikacja odczytuje klucz publiczny metadanych dla usługi Azure AD B2C, aby zweryfikować podpis odpowiedzi SAML.

Napiwek

Ten klucz zasad można użyć do innych celów, takich jak podpisywanie asercji SAML.

Uzyskiwanie certyfikatu

Jeśli nie masz jeszcze certyfikatu, możesz użyć certyfikatu z podpisem własnym. Certyfikat z podpisem własnym jest certyfikatem zabezpieczeń, który nie jest podpisany przez urząd certyfikacji i nie zapewnia gwarancji bezpieczeństwa certyfikatu podpisanego przez urząd certyfikacji.

Windows

W systemie Windows użyj polecenia cmdlet New-SelfSignedCertificate w programie PowerShell, aby wygenerować certyfikat.

1. Uruchom następujące polecenie programu PowerShell, aby wygenerować certyfikat z podpisem własnym. Zmodyfikuj -Subject argument odpowiednio dla aplikacji i nazwy dzierżawy usługi Azure AD B2C, na przykład contosowebapp.contoso.onmicrosoft.com. Możesz również dostosować -NotAfter datę, aby określić inne wygaśnięcie certyfikatu.

   New-SelfSignedCertificate `
       -KeyExportPolicy Exportable `
       -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
       -KeyAlgorithm RSA `
       -KeyLength 2048 `
       -KeyUsage DigitalSignature `
       -NotAfter (Get-Date).AddMonths(12) `
       -CertStoreLocation "Cert:\CurrentUser\My"
   

2. Na komputerze z systemem Windows wyszukaj i wybierz pozycję Zarządzaj certyfikatami użytkowników

3. W obszarze Certyfikaty — bieżący użytkownik wybierz pozycję Certyfikaty>osobiste>yourappname.yourtenant.onmicrosoft.com.

4. Wybierz certyfikat, a następnie wybierz pozycję Akcja>Wszystkie zadania>eksportu.

5. Wybierz pozycję Dalej>Tak, wyeksportuj klucz>prywatny Dalej.

6. Zaakceptuj wartości domyślne formatu pliku eksportu, a następnie wybierz przycisk Dalej.

7. Włącz opcję Hasło , wprowadź hasło dla certyfikatu, a następnie wybierz pozycję Dalej.

8. Aby określić lokalizację do zapisania certyfikatu, wybierz pozycję Przeglądaj i przejdź do wybranego katalogu.

9. W oknie Zapisz jako wprowadź nazwę pliku, a następnie wybierz pozycję Zapisz.

10. Wybierz pozycje Next>Finish (Dalej, Zakończ).

Aby usługa Azure AD B2C akceptowała hasło pliku pfx, należy zaszyfrować hasło przy użyciu opcji TripleDES-SHA1 w narzędziu eksportu magazynu certyfikatów systemu Windows, w przeciwieństwie do AES256-SHA256.

macOS

W systemie macOS użyj Asystenta certyfikatów w obszarze Dostęp łańcucha kluczy, aby wygenerować certyfikat.

1. Postępuj zgodnie z instrukcjami dotyczącymi tworzenia certyfikatów z podpisem własnym w programie Keychain Access na komputerze Mac.
2. W aplikacji Keychain Access na komputerze Mac wybierz utworzony certyfikat.
3. Wybierz pozycję Plik>Eksportuj elementy.
4. Wybierz nazwę pliku, aby zapisać certyfikat. Na przykład: self-signed-certificate.p12.
5. W obszarze Format pliku wybierz pozycję Wymiana informacji osobistych (p12).
6. Wybierz pozycję Zapisz.
7. Wprowadź hasło w polach Hasło i Sprawdź .
8. Zastąp rozszerzenie pliku plikiem pfx. Na przykład: self-signed-certificate.pfx.

Przekazywanie certyfikatu

Certyfikat należy przechowywać w dzierżawie usługi Azure AD B2C.

1. Zaloguj się w witrynie Azure Portal.
2. Jeśli masz dostęp do wielu dzierżaw, wybierz ikonę Ustawienia w górnym menu, aby przełączyć się do dzierżawy usługi Azure AD B2C z menu Katalogi i subskrypcje.
3. Wybierz pozycję Wszystkie usługi w lewym górnym rogu witryny Azure Portal, a następnie wyszukaj i wybierz pozycję Azure AD B2C.
4. Na stronie Przegląd wybierz pozycję Identity Experience Framework.
5. Wybierz pozycję Klucze zasad, a następnie wybierz pozycję Dodaj.
6. W obszarze Opcje wybierz pozycję Przekaż.
7. W polu Nazwa wprowadź nazwę klucza zasad. Na przykład wprowadź samlIdpCert. Prefiks B2C_1A_ jest dodawany automatycznie do nazwy klucza.
8. Przejdź do pliku pfx certyfikatu i wybierz go z kluczem prywatnym.
9. Wybierz pozycję Utwórz.

Włączanie nawiązywania połączenia z aplikacją SAML

Aby nawiązać połączenie z aplikacją SAML, usługa Azure AD B2C musi mieć możliwość tworzenia odpowiedzi SAML.

Otwórz plik SocialAndLocalAccounts\TrustFrameworkExtensions.xml w niestandardowym pakiecie startowym zasad.

Znajdź sekcję <ClaimsProviders> i dodaj następujący fragment kodu XML, aby zaimplementować generator odpowiedzi SAML:

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>

    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
      </CryptographicKeys>
      <InputClaims/>
      <OutputClaims/>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
    </TechnicalProfile>

    <!-- Session management technical profile for SAML-based tokens -->
    <TechnicalProfile Id="SM-Saml-issuer">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
    </TechnicalProfile>

  </TechnicalProfiles>
</ClaimsProvider>

Konfigurowanie identyfikatora URI wystawcy odpowiedzi SAML

Wartość elementu metadanych można zmienić IssuerUri w profilu technicznym wystawcy tokenu SAML. Ta zmiana zostanie odzwierciedlona w atrybucie issuerUri zwróconym w odpowiedzi SAML z usługi Azure AD B2C. Skonfiguruj aplikację tak, aby akceptowała tę samą IssuerUri wartość podczas walidacji odpowiedzi SAML.

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="IssuerUri">https://issuerUriMyAppExpects</Item>
      </Metadata>
      ...
    </TechnicalProfile>

Konfigurowanie zasad w celu wystawienia odpowiedzi SAML

Teraz, gdy zasady mogą tworzyć odpowiedzi SAML, należy skonfigurować zasady tak, aby wystawiały odpowiedź SAML zamiast domyślnej odpowiedzi JWT na aplikację.

Tworzenie zasad rejestracji lub logowania skonfigurowanych dla protokołu SAML

1. Utwórz kopię pliku SignUpOrSignin.xml w katalogu roboczym pakietu startowego i zapisz go pod nową nazwą. W tym artykule użyto przykładu SignUpOrSigninSAML.xml . Ten plik jest plikiem zasad dla jednostki uzależnionej. Domyślnie jest skonfigurowany do wystawiania odpowiedzi JWT.

2. Otwórz plik SignUpOrSigninSAML.xml w preferowanym edytorze.

3. Zmień wartość:

   1. PolicyId do B2C_1A_signup_signin_saml

   2. PublicPolicyUri do http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml. Zastąp <tenant-name> symbol zastępczy poddomeną nazwy domeny dzierżawy usługi Azure AD B2C. Jeśli na przykład domena podstawowa dzierżawy to contoso.onmicrosoft.com, użyj polecenia contoso. Jeśli nie masz swojej nazwy dzierżawy, dowiedz się , jak odczytywać szczegóły dzierżawy.

   <TrustFrameworkPolicy
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
   PolicySchemaVersion="0.3.0.0"
   TenantId="<tenant-name>.onmicrosoft.com"
   PolicyId="B2C_1A_signup_signin_saml"
   PublicPolicyUri="http://<tenant-name>.onmicrosoft.com/B2C_1A_signup_signin_saml">
   

4. Po zakończeniu podróży użytkownika usługa Azure AD B2C zawiera SendClaims krok. Ten krok odwołuje się do profilu technicznego wystawcy tokenu. Aby wydać odpowiedź SAML zamiast domyślnej odpowiedzi JWT, zmodyfikuj SendClaims krok, aby odwołać się do nowego profilu technicznego wystawcy tokenu SAML, Saml2AssertionIssuer.

Dodaj następujący fragment kodu XML tuż przed elementem <RelyingParty> . Ten kod XML zastępuje aranżację krok 7 w podróży użytkownika SignUpOrSignIn .

Jeśli rozpoczęto pracę z innego folderu w pakiecie startowym lub dostosowano podróż użytkownika przez dodanie lub usunięcie kroków aranżacji, upewnij się, że liczba w order elemencie odpowiada liczbie określonej w podróży użytkownika na potrzeby kroku wystawcy tokenu. Na przykład w innych folderach pakietów startowych odpowiedni numer kroku to 4 dla LocalAccounts, 6 dla SocialAccounts, i 9 dla SocialAndLocalAccountsWithMfa.

<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>
      <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys>

Element jednostki uzależnionej określa protokół używany przez aplikację. Wartość domyślna to OpenId. Element Protocol musi zostać zmieniony na SAML. Oświadczenia wyjściowe spowodują utworzenie mapowania oświadczeń na asercji SAML.

Zastąp cały <TechnicalProfile> element w elemencie <RelyingParty> następującym kodem XML profilu technicznego.

    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
    </TechnicalProfile>

Ostateczny plik zasad jednostki uzależnionej powinien wyglądać podobnie do następującego kodu XML:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TrustFrameworkPolicy
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06"
  PolicySchemaVersion="0.3.0.0"
  TenantId="contoso.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin_saml"
  PublicPolicyUri="http://contoso.onmicrosoft.com/B2C_1A_signup_signin_saml">

  <BasePolicy>
    <TenantId>contoso.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>

  <UserJourneys>
    <UserJourney Id="SignUpOrSignIn">
      <OrchestrationSteps>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="Saml2AssertionIssuer"/>
      </OrchestrationSteps>
    </UserJourney>
  </UserJourneys>

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="displayName" />
        <OutputClaim ClaimTypeReferenceId="givenName" />
        <OutputClaim ClaimTypeReferenceId="surname" />
        <OutputClaim ClaimTypeReferenceId="email" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="" />
        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
    </TechnicalProfile>
  </RelyingParty>
</TrustFrameworkPolicy>

Uwaga

Możesz wykonać ten sam proces, aby zaimplementować inne typy przepływów użytkownika (na przykład: logowanie, resetowanie hasła lub edytowanie profilów).

Przekazywanie zasad

Zapisz zmiany i przekaż nowe pliki zasad TrustFrameworkExtensions.xml i SignUpOrSigninSAML.xml do witryny Azure Portal.

Testowanie metadanych SAML dostawcy tożsamości usługi Azure AD B2C

Po przekazaniu plików zasad usługa Azure AD B2C używa informacji o konfiguracji do generowania dokumentu metadanych SAML dostawcy tożsamości, który będzie używany przez aplikację. Dokument metadanych SAML zawiera lokalizacje usług, takie jak metody logowania, metody wylogowywanie i certyfikaty.

Metadane zasad usługi Azure AD B2C są dostępne pod następującym adresem URL:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/samlp/metadata

Zastąp <tenant-name> ciąg nazwą dzierżawy usługi Azure AD B2C. Zastąp <policy-name> ciąg nazwą (ID) zasad. Oto przykład:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/metadata

Rejestrowanie aplikacji SAML w usłudze Azure AD B2C

Aby usługa Azure AD B2C ufała aplikacji, należy utworzyć rejestrację aplikacji usługi Azure AD B2C. Rejestracja zawiera informacje o konfiguracji, takie jak punkt końcowy metadanych aplikacji.

1. Zaloguj się w witrynie Azure Portal.
2. Jeśli masz dostęp do wielu dzierżaw, wybierz ikonę Ustawienia w górnym menu, aby przełączyć się do dzierżawy usługi Azure AD B2C z menu Katalogi i subskrypcje.
3. W menu po lewej stronie wybierz pozycję Azure AD B2C. Możesz też wybrać pozycję Wszystkie usługi , a następnie wyszukać i wybrać pozycję Azure AD B2C.
4. Wybierz pozycję Rejestracje aplikacji, a następnie wybierz pozycję Nowa rejestracja.
5. Wprowadź nazwę aplikacji. Na przykład wprowadź SAMLApp1.
6. W obszarze Obsługiwane typy kont wybierz pozycję Konta tylko w tym katalogu organizacyjnym.
7. W obszarze Identyfikator URI przekierowania wybierz pozycję Sieć Web, a następnie wprowadź wartość https://localhost. Zmodyfikujesz tę wartość później w manifeście rejestracji aplikacji.
8. Wybierz pozycję Zarejestruj.

Konfigurowanie aplikacji w usłudze Azure AD B2C

W przypadku aplikacji SAML należy skonfigurować kilka właściwości w manifeście rejestracji aplikacji.

1. W witrynie Azure Portal przejdź do rejestracji aplikacji utworzonej w poprzedniej sekcji.
2. W obszarze Zarządzaj wybierz pozycję Manifest , aby otworzyć edytor manifestu. Następnie zmodyfikuj właściwości opisane w poniższych sekcjach.

Dodawanie identyfikatora

Gdy aplikacja SAML wysyła żądanie do usługi Azure AD B2C, żądanie SAML AuthN zawiera Issuer atrybut. Wartość tego atrybutu jest zwykle taka sama jak wartość metadanych entityID aplikacji. Usługa Azure AD B2C używa tej wartości do wyszukania rejestracji aplikacji w katalogu i odczytania konfiguracji. Aby to wyszukiwanie powiodło się, identifierUri w rejestracji aplikacji musi zostać wypełniona wartością zgodną z atrybutem Issuer .

W manifeście rejestracji znajdź identifierURIs parametr i dodaj odpowiednią wartość. Ta wartość będzie taka sama, jak wartość skonfigurowana w żądaniach AuthN protokołu SAML dla EntityId aplikacji oraz entityID wartość w metadanych aplikacji. Należy również znaleźć accessTokenAcceptedVersion parametr i ustawić wartość na 2.

Ważne

Jeśli nie zaktualizujesz accessTokenAcceptedVersion 2 elementu , zostanie wyświetlony komunikat o błędzie wymagający zweryfikowanej domeny.

Poniższy przykład przedstawia entityID wartość w metadanych JĘZYKA SAML:

<EntityDescriptor ID="id123456789" entityID="https://samltestapp2.azurewebsites.net" validUntil="2099-12-31T23:59:59Z" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

Właściwość identifierUris będzie akceptować adresy URL tylko w domenie tenant-name.onmicrosoft.com.

"identifierUris":"https://tenant-name.onmicrosoft.com/app-name",

Udostępnianie metadanych aplikacji w usłudze Azure AD B2C

Po załadowaniu rejestracji aplikacji przez jej identifierUri wartość usługa Azure AD B2C używa metadanych aplikacji do sprawdzania poprawności żądania AuthN protokołu SAML i określenia, jak odpowiedzieć.

Zalecamy, aby aplikacja uwidacznia publicznie dostępny punkt końcowy metadanych.

Jeśli istnieją właściwości określone zarówno w adresie URL metadanych SAML, jak i w manifeście rejestracji aplikacji, są one scalane. Właściwości określone w adresie URL metadanych są najpierw przetwarzane i mają pierwszeństwo.

Korzystając z przykładowej aplikacji testowej SAML, należy użyć następującej wartości samlMetadataUrl w manifeście aplikacji:

"samlMetadataUrl":"https://samltestapp2.azurewebsites.net/Metadata",

Zastąpij lub ustaw adres URL odbiorcy asercji (opcjonalnie)

Adres URL odpowiedzi, do którego usługa Azure AD B2C wysyła odpowiedzi SAML. Adresy URL odpowiedzi można skonfigurować w manifeście aplikacji. Ta konfiguracja jest przydatna, gdy aplikacja nie uwidacznia publicznie dostępnego punktu końcowego metadanych.

Adres URL odpowiedzi dla aplikacji SAML to punkt końcowy, w którym aplikacja oczekuje odbierania odpowiedzi SAML. Aplikacja zwykle udostępnia ten adres URL w dokumencie metadanych jako Location atrybut AssertionConsumerService elementu, jak pokazano w tym przykładzie:

<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    ...
    <AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://samltestapp2.azurewebsites.net/SP/AssertionConsumer" />        
</SPSSODescriptor>

Jeśli brakuje elementu metadanych AssertionConsumerService aplikacji lub chcesz go zastąpić, skonfiguruj właściwość manifestu replyUrlsWithType rejestracji aplikacji. Usługa Azure AD B2C używa elementu replyUrlsWithType do przekierowywania użytkowników po zalogowaniu HTTP-POST się przy użyciu typu powiązania.

Korzystając z przykładowej aplikacji testowej SAML, należy ustawić url właściwość replyUrlsWithType na wartość pokazaną w poniższym fragmencie kodu JSON:

"replyUrlsWithType":[
  {
    "url":"https://samltestapp2.azurewebsites.net/SP/AssertionConsumer",
    "type":"Web"
  }
],

Zastąpij lub ustaw adres URL wylogowywania (opcjonalnie)

Adres URL wylogowywania definiuje miejsce przekierowania użytkownika po żądaniu wylogowania. Aplikacja zwykle udostępnia ten adres URL w dokumencie metadanych jako Location atrybut SingleLogoutService elementu, jak pokazano w poniższym przykładzie:

<SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://samltestapp2.azurewebsites.net/logout" ResponseLocation="https://samltestapp2.azurewebsites.net/logout" />

</SPSSODescriptor>

Jeśli brakuje elementu metadanych SingleLogoutService aplikacji, skonfiguruj właściwość manifestu logoutUrl rejestracji aplikacji. Usługa Azure AD B2C używa elementu logoutURL do przekierowywania użytkowników po wylogowaniu HTTP-Redirect się przy użyciu typu powiązania.

Korzystając z przykładowej aplikacji testowej SAML, należy ustawić logoutUrl właściwość na https://samltestapp2.azurewebsites.net/logout:

"logoutUrl": "https://samltestapp2.azurewebsites.net/logout",

Uwaga

Jeśli zdecydujesz się skonfigurować adres URL odpowiedzi i adres URL wylogowywania w manifeście aplikacji bez wypełniania punktu końcowego metadanych aplikacji za pośrednictwem samlMetadataUrl właściwości, usługa Azure AD B2C nie zweryfikuje podpisu żądania SAML. Nie będzie też szyfrować odpowiedzi SAML.

Konfigurowanie usługi Azure AD B2C jako dostawcy tożsamości SAML w aplikacji SAML

Ostatnim krokiem jest włączenie usługi Azure AD B2C jako dostawcy tożsamości SAML w aplikacji SAML. Każda aplikacja jest inna, a kroki różnią się. Aby uzyskać szczegółowe informacje, zapoznaj się z dokumentacją aplikacji.

Metadane można skonfigurować w aplikacji jako metadane statyczne lub metadane dynamiczne. W trybie statycznym skopiuj wszystkie lub część metadanych z metadanych zasad usługi Azure AD B2C. W trybie dynamicznym podaj adres URL metadanych i zezwól aplikacji na dynamiczne odczytywanie metadanych.

Niektóre lub wszystkie następujące elementy są zwykle wymagane:

• Metadane: użyj formatu https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/Samlp/metadata.

• Wystawcaissuer: wartość żądania SAML musi być zgodna z jednym z identyfikatorów URI skonfigurowanych w identifierUris elemencie manifestu rejestracji aplikacji. Jeśli nazwa żądania issuer SAML nie istnieje w elemecie identifierUris , dodaj ją do manifestu rejestracji aplikacji. Na przykład: https://contoso.onmicrosoft.com/app-name.

• Adres URL logowania, punkt końcowy SAML, adres URL języka SAML: sprawdź wartość w pliku metadanych zasad SAML usługi Azure AD B2C dla <SingleSignOnService> elementu XML.

• Certyfikat: ten certyfikat jest B2C_1A_SamlIdpCert, ale bez klucza prywatnego. Aby uzyskać klucz publiczny certyfikatu:

  1. Przejdź do określonego wcześniej adresu URL metadanych.
  2. Skopiuj wartość w elemecie <X509Certificate> .
  3. Wklej go do pliku tekstowego.
  4. Zapisz plik tekstowy jako plik cer .

Testowanie za pomocą aplikacji testowej SAML

Aby przetestować konfigurację, możesz użyć naszej aplikacji testowej SAML:

• Zaktualizuj nazwę dzierżawy.
• Zaktualizuj nazwę zasad. Na przykład użyj B2C_1A_signup_signin_saml.
• Określ identyfikator URI wystawcy. Użyj jednego z identyfikatorów URI znalezionych w elemecie identifierUris w manifeście rejestracji aplikacji. Użyj na przykład nazwy https://contoso.onmicrosoft.com/app-name.

Wybierz pozycję Zaloguj się, a ekran logowania użytkownika powinien zostać wyświetlony. Po zalogowaniu zostanie wydana odpowiedź SAML z powrotem do przykładowej aplikacji.

Obsługiwane i nieobsługiwane modalności JĘZYKA SAML

Następujące scenariusze aplikacji SAML są obsługiwane za pośrednictwem własnego punktu końcowego metadanych:

• Określ wiele adresów URL wylogowywania lub powiązania POST dla adresu URL wylogowywania w obiekcie aplikacji lub jednostki usługi.
• Określ klucz podpisywania, aby zweryfikować żądania jednostki uzależnionej w obiekcie aplikacji lub jednostki usługi.
• Określ klucz szyfrowania tokenu w obiekcie aplikacji lub jednostki usługi.
• Określ logowanie inicjowane przez dostawcę tożsamości, w którym dostawca tożsamości jest usługą Azure AD B2C.

Następne kroki

• Pobierz testową aplikację internetową SAML z repozytorium społeczności usługi GitHub usługi Azure AD B2C.
• Zobacz opcje rejestrowania aplikacji SAML w usłudze Azure AD B2C.
• Dowiedz się, jak tworzyć odporność za pomocą najlepszych rozwiązań dla deweloperów.