Konfigurowanie rozwiązania Asignio przy użyciu usługi Azure Active Directory B2C na potrzeby uwierzytelniania wieloskładnikowego

Dowiedz się, jak zintegrować uwierzytelnianie microsoft Entra ID (Azure AD B2C) z aplikacją Asignio. Dzięki tej integracji zapewnij klientom środowisko uwierzytelniania bez hasła, miękkie biometryczne oraz wieloskładnikowe. Usługa Asignio używa patentowanej sygnatury Asignio i weryfikacji twarzy na żywo na potrzeby uwierzytelniania użytkowników. Zmienialny podpis biometryczny pomaga zmniejszyć liczbę haseł, oszustw, wyłudzania informacji i ponownego użycia poświadczeń za pośrednictwem uwierzytelniania wielokanałowego.

Zanim rozpoczniesz

Wybierz selektor typów zasad, aby wskazać konfigurację typu zasad. Usługa Azure AD B2C ma dwie metody definiowania sposobu interakcji użytkowników z aplikacjami:

• Wstępnie zdefiniowane przepływy użytkowników
• Konfigurowalne zasady niestandardowe

Kroki opisane w tym artykule różnią się w zależności od metody.

Więcej informacji:

• Omówienie przepływów użytkownika i zasad niestandardowych
• Omówienie zasad niestandardowych usługi Azure AD B2C

Wymagania wstępne

• Subskrypcja platformy Azure.

• Jeśli nie masz konta, uzyskaj bezpłatne konto platformy Azure

• Instancja Azure AD B2C połączona z subskrypcją platformy Azure

• Zobacz Samouczek: tworzenie dzierżawcy usługi Azure Active Directory B2C

• Identyfikator klienta asignio i klucz tajny klienta wystawiony przez usługę Asignio.

• Te tokeny są uzyskiwane przez zarejestrowanie aplikacji mobilnych lub internetowych w usłudze Asignio.

W przypadku zasad niestandardowych

Pełny samouczek: jak stworzyć przepływy użytkowników i polityki niestandardowe w usłudze Azure AD B2C

Opis scenariusza

Ta integracja obejmuje następujące składniki:

• Azure AD B2C — serwer autoryzacji, który weryfikuje poświadczenia użytkownika
• Aplikacje internetowe lub mobilne — aby zabezpieczyć się za pomocą usługi Asignio MFA
• Aplikacja internetowa Asignio — zbieranie biometryczne podpisów na urządzeniu dotykowym użytkownika

Na poniższym diagramie przedstawiono implementację.

1. Użytkownik otwiera stronę logowania usługi Azure AD B2C w swojej aplikacji mobilnej lub internetowej, a następnie loguje się lub rejestruje.
2. Usługa Azure AD B2C przekierowuje użytkownika do aplikacji Asignio przy użyciu żądania OpenID Connect (OIDC).
3. Użytkownik jest przekierowywany do aplikacji internetowej Asignio na potrzeby logowania biometrycznego. Jeśli użytkownik nie zarejestrował swojego podpisu Asignio, może użyć wiadomości SMS One-Time-Password (OTP) do uwierzytelnienia. Po uwierzytelnieniu użytkownik otrzyma link rejestracji w celu utworzenia podpisu Asignio.
4. Użytkownik uwierzytelnia się przy użyciu funkcji Asignio Signature i weryfikacji twarzy lub weryfikacji głosu i twarzy.
5. Odpowiedź na wyzwanie jest kierowana do Asignio.
6. Narzędzie Asignio zwraca odpowiedź OIDC podczas logowania do usługi Azure AD B2C.
7. Usługa Azure AD B2C wysyła żądanie weryfikacji uwierzytelniania do aplikacji Asignio w celu potwierdzenia otrzymania danych uwierzytelniania.
8. Użytkownik otrzymuje lub odmawia dostępu do aplikacji.

Konfigurowanie aplikacji przy użyciu rozwiązania Asignio

Konfigurowanie aplikacji z usługą Asignio odbywa się przy użyciu witryny administracyjnej partnera Asignio.

1. Aby zażądać dostępu do organizacji, przejdź do strony asignio.com Administracja partnerem Asignio .
2. Za pomocą poświadczeń zaloguj się do aplikacji Asignio Partner Administration.
3. Utwórz rekord dla aplikacji Azure AD B2C, korzystając z dzierżawy Azure AD B2C. W przypadku korzystania z usługi Azure AD B2C z aplikacją Asignio usługa Azure AD B2C zarządza połączonymi aplikacjami. Aplikacje Asignio reprezentują aplikacje w witrynie Azure Portal.
4. W witrynie administracyjnej partnera Asignio wygeneruj identyfikator klienta i tajny klienta.
5. Zanotuj i zapisz identyfikator klienta i klucz tajny klienta. Będą one używane później. Usługa Asignio nie przechowuje tajnych danych klientów.
6. Wprowadź identyfikator URI przekierowania w witrynie, do której użytkownik jest zwracany po uwierzytelnieniu. Użyj następującego wzorca identyfikatora URI.

[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp].

7. Przekaż logo firmy. Jest on wyświetlany podczas uwierzytelniania Asignio po zalogowaniu się przez użytkowników.

Rejestrowanie aplikacji internetowej w usłudze Azure AD B2C

Zarejestruj aplikacje w dzierżawie, którą zarządzasz, aby mogły następnie wchodzić w interakcję z usługą Azure AD B2C.

Dowiedz się więcej: Typy aplikacji, których można używać w usłudze Active Directory B2C

W tym samouczku rejestrujesz https://jwt.msaplikację internetową firmy Microsoft z zdekodowanym tokenem, która nie opuszcza przeglądarki.

Rejestrowanie aplikacji internetowej

Wykonaj kroki opisane w artykule Samouczek: rejestrowanie aplikacji internetowej w usłudze Azure Active Directory B2C .

Konfigurowanie aplikacji Asignio jako dostawcy tożsamości w usłudze Azure AD B2C

Aby uzyskać poniższe instrukcje, użyj dzierżawy firmy Microsoft Entra z subskrypcją platformy Azure.

1. Zaloguj się do portalu Azure jako co najmniej administrator zasad IEF B2C w dzierżawie usługi Azure AD B2C.
2. Na pasku narzędzi witryny Azure Portal wybierz pozycję Katalogi i subskrypcje.
3. Ustawienia portalu | Katalogi i subskrypcje na liście Nazwa katalogu znajdź katalog Microsoft Entra.
4. Wybierz opcję Przełącz.
5. W lewym górnym rogu witryny Azure Portal wybierz pozycję Wszystkie usługi.
6. Wyszukaj i wybierz Azure AD B2C.
7. W witrynie Azure Portal wyszukaj i wybierz pozycję Azure AD B2C.
8. W menu po lewej stronie wybierz pozycję Dostawcy tożsamości.
9. Wybierz Nowego dostawcę OpenID Connect.
10. Wybierz Typ dostawcy tożsamości>OpenID Connect.
11. W polu Nazwa wprowadź nazwę logowania Asignio lub wybraną nazwę.
12. W polu Adres URL metadanych wpisz https://authorization.asignio.com/.well-known/openid-configuration.
13. W polu Identyfikator klienta wprowadź wygenerowany identyfikator klienta.
14. W polu Klucz tajny klienta wprowadź wygenerowany klucz tajny klienta.
15. Dla Zakresu użyj openid email profile.
16. W polu Typ odpowiedzi użyj kodu.
17. W przypadku trybu odpowiedzi użyj zapytania.
18. W przypadku wskazówek dotyczących domeny użyj polecenia https://asignio.com.
19. Kliknij przycisk OK.
20. Wybierz pozycję Mapuj oświadczenia tego dostawcy tożsamości.
21. W przypadku identyfikatora użytkownika użyj sub.
22. W polu Nazwa wyświetlana użyj nazwy.
23. W polu Imię i nazwisko użyj given_name.
24. W przypadku nazwiska użyj family_name.
25. W przypadku email użyj adresu e-mail.
26. Wybierz Zapisz.

Tworzenie zasad przepływu użytkownika

1. W dzierżawie usługi Azure AD B2C w sekcji Zasady wybierz pozycję Przepływy użytkownika.
2. Wybierz pozycję Nowy przepływ użytkownika.
3. Wybierz pozycję Zarejestruj się i zaloguj się jako typ przepływu użytkownika.
4. Wybierz pozycję Zalecana wersja.
5. Wybierz Utwórz.
6. Wprowadź nazwę przepływu użytkownika, taką jak AsignioSignupSignin.
7. W obszarze Dostawcy tożsamości w obszarze Konta lokalne wybierz pozycję Brak. Ta akcja powoduje wyłączenie uwierzytelniania wiadomości e-mail i hasła.
8. W polu Niestandardowi dostawcy tożsamości wybierz utworzonego dostawcę tożsamości Asignio.
9. Wybierz Utwórz.

Testowanie przepływu użytkownika

1. W dzierżawie Azure AD B2C wybierz opcję Przepływy użytkownika.
2. Wybierz utworzony przepływ użytkownika.
3. W polu Aplikacja wybierz zarejestrowaną aplikację internetową. Adres URL odpowiedzi to https://jwt.ms.
4. Wybierz Uruchom przepływ użytkownika.
5. Przeglądarka jest przekierowywana do strony logowania do aplikacji Asignio.
6. Zostanie wyświetlony ekran logowania.
7. Na dole wybierz uwierzytelnianie Asignio.

Jeśli masz podpis Asignio, ukończ monit o uwierzytelnienie. Jeśli nie, podaj numer telefonu urządzenia, aby uwierzytelnić się za pośrednictwem SMS z kodem OTP. Użyj linku, aby zarejestrować podpis Asignio.

8. Przeglądarka jest przekierowywana do https://jwt.ms. Zostanie wyświetlona zawartość tokenu zwrócona przez usługę Azure AD B2C.

Tworzenie klucza zasad Asignio

1. Zapisz wygenerowany sekret klienta w dzierżawie Azure AD B2C.
2. Zaloguj się do witryny Azure Portal.
3. Na pasku narzędzi portalu wybierz katalogi i subskrypcje.
4. Ustawienia portalu | Katalogi i subskrypcje na liście Nazwa katalogu znajdź katalog usługi Azure AD B2C.
5. Wybierz opcję Przełącz.
6. W lewym górnym rogu witryny Azure Portal wybierz pozycję Wszystkie usługi.
7. Wyszukaj i wybierz Azure AD B2C.
8. Na stronie Przegląd ogólny wybierz pozycję Identity Experience Framework.
9. Wybierz Klucze zasad.
10. Wybierz Dodaj.
11. W obszarze Opcje wybierz pozycję Ręczne.
12. Wprowadź klucz polityki Nazwa dla klucza polityki. Prefiks B2C_1A_ jest dołączany do nazwy klucza.
13. W polu Wpis tajny wprowadź zanotowany klucz tajny klienta.
14. W obszarze Użycie klucza wybierz pozycję Podpis.
15. Wybierz Utwórz.

Skonfiguruj Asignio jako dostawcę tożsamości

Aby użytkownicy mogli zalogować się za pomocą Asignio, zdefiniuj Asignio jako dostawcę tożsamości, z którym usługa Azure AD B2C komunikuje się przez punkt końcowy. Punkt końcowy udostępnia oświadczenia, których usługa Azure AD B2C używa do weryfikowania uwierzytelniania użytkownika przy użyciu identyfikatora cyfrowego na urządzeniu.

Dodaj Asignio jako dostawcę oświadczeń

Pobierz pakiety początkowe zasad niestandardowych z usługi GitHub, a następnie zaktualizuj pliki XML w pakiecie startowym LocalAccounts przy użyciu nazwy dzierżawy usługi Azure AD B2C:

1. Pobierz plik zip o nazwie active-directory-b2c-custom-policy-starterpack lub sklonuj repozytorium.

       git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
   

2. W plikach w katalogu LocalAccounts zastąp ciąg yourtenant nazwą dzierżawy usługi Azure AD B2C.

3. Otwórz LocalAccounts/ TrustFrameworkExtensions.xml.

4. Znajdź element ClaimsProviders . Jeśli go nie ma, dodaj go pod elementem głównym , TrustFrameworkPolicy.

5. Dodaj nowy element ClaimsProvider podobny do następującego przykładu:

    <ClaimsProvider>
      <Domain>contoso.com</Domain>
      <DisplayName>Asignio</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Asignio-Oauth2">
          <DisplayName>Asignio</DisplayName>
          <Description>Login with your Asignio account</Description>
          <Protocol Name="OAuth2" />
          <Metadata>
            <Item Key="ProviderName">authorization.asignio.com</Item>
            <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>
            <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>
            <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>
            <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>
            <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="scope">openid profile email</Item>
            <Item Key="UsePolicyInRedirectUri">0</Item>
            <!-- Update the Client ID below to the Asignio Application ID -->
            <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
            <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
   
   
            <!-- trying to add additional claim-->
            <!--Insert b2c-extensions-app application ID here, for example: 00001111-aaaa-2222-bbbb-3333cccc4444-->
            <Item Key="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
            <!--Insert b2c-extensions-app application ObjectId here, for example: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb-->
            <Item Key="aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"></Item>
            <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
            <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/00001111-aaaa-2222-bbbb-3333cccc4444</Item>-->
            <!-- The commented key below specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to     sign in. -->
            <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
          </CryptographicKeys>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
            <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authorization.asignio.com" />
            <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
   

6. Ustaw client_id przy użyciu zanotowanego identyfikatora aplikacji Asignio.

7. Zaktualizuj sekcję client_secret przy użyciu utworzonego klucza zasad. Na przykład : B2C_1A_AsignioSecret

   <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
   

8. Zapisz zmiany.

Dodanie ścieżki użytkownika

Dostawca tożsamości nie znajduje się na stronach logowania.

1. Jeśli masz niestandardową podróż użytkownika, przejdź do sekcji Konfigurowanie zasad jednostki uzależnionej, w przeciwnym razie skopiuj podróż użytkownika szablonu:
2. W pakiecie startowym otwórz plik LocalAccounts/ TrustFrameworkBase.xml.
3. Znajdź i skopiuj zawartość elementu UserJourney , który zawiera Id=SignUpOrSignInelement .
4. Otwórz LocalAccounts/ TrustFrameworkExtensions.xml.
5. Znajdź element UserJourneys . Jeśli go nie ma, dodaj go.
6. Wklej zawartość elementu UserJourney jako element podrzędny elementu UserJourneys.]
7. Zmień nazwę podróży użytkownika ID. Na przykład Id=AsignioSUSI.

Dowiedz się więcej: Podróże użytkowników

Dodaj dostawcę tożsamości do podróży użytkownika

Dodaj nowego dostawcę tożsamości do ścieżki użytkownika.

1. Znajdź element kroku aranżacji, który zawiera Type=CombinedSignInAndSignUp lub Type=ClaimsProviderSelection w ścieżce użytkownika. Zazwyczaj jest to pierwszy krok aranżacji. Element ClaimsProviderSelections ma listę dostawców tożsamości, za pomocą których użytkownicy loguje się. Kolejność elementów kontroluje kolejność przycisków logowania.
2. Dodaj element XML ClaimsProviderSelection.
3. Ustaw wartość TargetClaimsExchangeId na przyjazną nazwę.
4. Dodaj element ClaimsExchange .
5. Ustaw identyfikator na wartość docelowego identyfikatora wymiany oświadczeń.
6. Zaktualizuj wartość TechnicalProfileReferenceId na identyfikator utworzonego profilu technicznego.

Poniższy kod XML przedstawia aranżację podróży użytkownika z dostawcą tożsamości.

    <UserJourney Id="AsignioSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent            in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>socialIdpAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->
        <OrchestrationStep Order="6" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

Konfigurowanie polityki podmiotu polegającego

Polityka zaufanej strony, na przykład SignUpSignIn.xml, określa ścieżkę użytkownika realizowaną przez Azure AD B2C.

1. W zaufanej stronie znajdź element DefaultUserJourney.
2. Zaktualizuj identyfikator ReferenceId , aby był zgodny z identyfikatorem podróży użytkownika, w którym dodano dostawcę tożsamości.

W poniższym przykładzie dla ścieżki użytkownika AsignioSUSI identyfikator ReferenceId jest ustawiony na:AsignioSUSI

   <RelyingParty>
        <DefaultUserJourney ReferenceId="AsignioSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" />
            <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

Przekaż zasady niestandardowe

1. Zaloguj się do witryny Azure Portal.
2. Na pasku narzędzi portalu wybierz katalogi i subskrypcje.
3. Ustawienia portalu | Katalogi i subskrypcje na liście Nazwa katalogu znajdź katalog usługi Azure AD B2C.
4. Wybierz opcję Przełącz.
5. W witrynie Azure Portal wyszukaj i wybierz pozycję Azure AD B2C.
6. W sekcji Zasady wybierz pozycję Identity Experience Framework.
7. Wybierz Przekaż niestandardową politykę.
8. Przekaż dwa zmienione pliki zasad w następującej kolejności:

• Polityka rozszerzeń, na przykład TrustFrameworkExtensions.xml
• Zasady podmiotu polegającego, takie jak SignUpOrSignin.xml

Przetestuj swoje zasady niestandardowe

1. W dzierżawie usługi Azure AD B2C, w sekcji Zasady, wybierz Identity Experience Framework.
2. W sekcji Zasady niestandardowe wybierz AsignioSUSI.
3. W polu Aplikacja wybierz zarejestrowaną aplikację internetową. Adres URL odpowiedzi to https://jwt.ms.
4. Wybierz opcję Uruchom teraz.
5. Przeglądarka jest przekierowywana do strony logowania do aplikacji Asignio.
6. Zostanie wyświetlony ekran logowania.
7. Na dole wybierz uwierzytelnianie Asignio.

Jeśli masz podpis Asignio, zostanie wyświetlony monit o uwierzytelnienie przy użyciu podpisu Asignio. Jeśli nie, podaj numer telefonu urządzenia, aby uwierzytelnić się za pośrednictwem SMS z kodem OTP. Użyj linku, aby zarejestrować podpis Asignio.

8. Przeglądarka jest przekierowywana do https://jwt.ms. Zostanie wyświetlona zawartość tokenu zwrócona przez usługę Azure AD B2C.

Dalsze kroki

• Rozwiązania i szkolenia dotyczące usługi Azure Active Directory B2C
• Zadawanie pytań w witrynie Stack Overflow
• Przykłady usługi Azure AD B2C
• YouTube: Seria Azure AD B2C: Tożsamość
• Omówienie zasad niestandardowych usługi Azure AD B2C
• Samouczek: tworzenie przepływów użytkownika i zasad niestandardowych w usłudze Azure Active Directory B2C