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 usługą Asignio. Dzięki tej integracji klienci mogą korzystać z funkcji bez hasła, miękkiej biometrii i uwierzytelniania wieloskładnikowego. Usługa Asignio używa patentowego podpisu Asignio Signature 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. 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
Dzierżawa usługi Azure AD B2C połączona z subskrypcją platformy Azure
Zobacz Samouczek: tworzenie dzierżawy 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
Kompletny samouczek: tworzenie przepływów użytkownika i zasad niestandardowych 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 — w celu zabezpieczenia za pomocą usługi Asignio MFA
- Aplikacja internetowa Asignio — kolekcja biometryczna podpisu na urządzeniu dotykowym użytkownika
Na poniższym diagramie przedstawiono implementację.
- Użytkownik otwiera Azure AD stronie logowania B2C na swojej aplikacji mobilnej lub internetowej, a następnie loguje się lub rejestruje.
- Azure AD B2C przekierowuje użytkownika do usługi Asignio przy użyciu żądania OpenID Connect (OIDC).
- Użytkownik jest przekierowywany do aplikacji internetowej Asignio w celu logowania biometrycznego. Jeśli użytkownik nie zarejestrował swojego podpisu Asignio, może użyć jednorazowego hasła sms (OTP) do uwierzytelnienia. Po uwierzytelnieniu użytkownik otrzyma link rejestracji w celu utworzenia podpisu Asignio.
- Użytkownik uwierzytelnia się przy użyciu funkcji Asignio Signature i weryfikacji twarzy lub weryfikacji głosu i twarzy.
- Odpowiedź na żądanie jest kierowana do aplikacji Asignio.
- Narzędzie Asignio zwraca odpowiedź OIDC na logowanie Azure AD B2C.
- Azure AD B2C wysyła żądanie weryfikacji uwierzytelniania do usługi Asignio w celu potwierdzenia otrzymania danych uwierzytelniania.
- Użytkownik otrzymuje lub odmawia dostępu do aplikacji.
Konfigurowanie aplikacji przy użyciu rozwiązania Asignio
Konfigurowanie aplikacji za pomocą rozwiązania Asignio odbywa się za pomocą witryny administracyjnej partnera Asignio.
- Przejdź do strony asignio.com Asignio Partner Administration (Administracja partnerem Asignio ), aby poprosić o dostęp do organizacji.
- Przy użyciu poświadczeń zaloguj się do aplikacji Asignio Partner Administration.
- Utwórz rekord dla aplikacji Azure AD B2C przy użyciu dzierżawy usługi Azure AD B2C. Gdy używasz Azure AD B2C z usługą Asignio, Azure AD B2C zarządza połączonymi aplikacjami. Aplikacje Asignio reprezentują aplikacje w Azure Portal.
- W lokacji administracyjnej partnera Asignio wygeneruj identyfikator klienta i klucz tajny klienta.
- Zanotuj i zapisz identyfikator klienta oraz klucz tajny klienta. Będą one używane później. Usługa Asignio nie przechowuje wpisów tajnych klienta.
- Wprowadź identyfikator URI przekierowania w witrynie, do których 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]
.
- Przekaż logo firmy. Jest ono wyświetlane podczas uwierzytelniania Asignio po zalogowaniu się użytkowników.
Rejestrowanie aplikacji internetowej w usłudze Azure AD B2C
Zarejestruj aplikacje w dzierżawie, którą zarządzasz, a następnie mogą wchodzić w interakcje z 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.ms
aplikację internetową firmy Microsoft z zdekodowanym tokenem zawartości, która nie opuszcza przeglądarki.
Rejestrowanie aplikacji internetowej i włączanie niejawnego przyznawania tokenu identyfikatora
Kompletny samouczek: rejestrowanie aplikacji internetowej w usłudze Azure Active Directory B2C
Konfigurowanie Asignio jako dostawcy tożsamości w usłudze Azure AD B2C
Aby uzyskać poniższe instrukcje, użyj dzierżawy Microsoft Entra z subskrypcją platformy Azure.
- Zaloguj się do Azure Portal jako administrator globalny dzierżawy usługi Azure AD B2C.
- Na pasku narzędzi Azure Portal wybierz pozycję Katalogi i subskrypcje.
- Ustawienia portalu | Katalogi i subskrypcje na liście Nazwa katalogu znajdź katalog Microsoft Entra.
- Wybierz pozycję Przełącz.
- W lewym górnym rogu Azure Portal wybierz pozycję Wszystkie usługi.
- Wyszukaj i wybierz pozycję Azure AD B2C.
- W Azure Portal wyszukaj i wybierz pozycję Azure AD B2C.
- W menu po lewej stronie wybierz pozycję Dostawcy tożsamości.
- Wybierz pozycję Nowy dostawca OpenID Connect.
- Wybierz typ >dostawcy tożsamościOpenID Connect.
- W polu Nazwa wprowadź nazwę logowania Asignio lub wybraną nazwę.
- W polu Adres URL metadanych wprowadź wartość
https://authorization.asignio.com/.well-known/openid-configuration
. - W polu Identyfikator klienta wprowadź wygenerowany identyfikator klienta.
- W polu Klucz tajny klienta wprowadź wygenerowany klucz tajny klienta.
- W polu Zakres użyj profilu openid poczty e-mail.
- W polu Typ odpowiedzi użyj kodu.
- W przypadku trybu odpowiedzi użyj zapytania.
- W przypadku wskazówek dotyczących domeny użyj polecenia
https://asignio.com
. - Wybierz przycisk OK.
- Wybierz pozycję Mapuj oświadczenia tego dostawcy tożsamości.
- W obszarze Identyfikator użytkownika użyj podgrupy.
- W polu Nazwa wyświetlana użyj nazwy.
- W polu Given Name (Imię i nazwisko) użyj given_name.
- W przypadku nazwiska użyj family_name.
- W przypadku aplikacji Email użyj adresu e-mail.
- Wybierz pozycję Zapisz.
Tworzenie zasad przepływu użytkownika
- W dzierżawie usługi Azure AD B2C w obszarze Zasady wybierz pozycję Przepływy użytkownika.
- Wybierz pozycję Nowy przepływ użytkownika.
- Wybierz pozycję Zarejestruj się i zaloguj się typ przepływu użytkownika.
- Wybierz pozycję Zalecana wersja.
- Wybierz przycisk Utwórz.
- Wprowadź nazwę przepływu użytkownika, na przykład
AsignioSignupSignin
. - W obszarze Dostawcy tożsamości w obszarze Konta lokalne wybierz pozycję Brak. Ta akcja wyłącza uwierzytelnianie za pomocą poczty e-mail i hasła.
- W przypadku niestandardowych dostawców tożsamości wybierz utworzonego dostawcę tożsamości Asignio.
- Wybierz przycisk Utwórz.
Testowanie przepływu użytkownika
- W dzierżawie usługi Azure AD B2C wybierz pozycję Przepływy użytkownika.
- Wybierz utworzony przepływ użytkownika.
- W polu Aplikacja wybierz zarejestrowaną aplikację internetową.
Adres URL odpowiedzi to
https://jwt.ms
. - Wybierz pozycję Uruchom przepływ użytkownika.
- Przeglądarka jest przekierowywana do strony logowania Asignio.
- Zostanie wyświetlony ekran logowania.
- W dolnej części wybierz pozycję Uwierzytelnianie Asignio .
Jeśli masz podpis Asignio, ukończ monit o uwierzytelnienie. Jeśli tak nie jest, podaj numer telefonu urządzenia, aby uwierzytelnić się za pośrednictwem protokołu SMS OTP. Użyj linku, aby zarejestrować swoją sygnaturę Asignio.
- 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
- Zapisz wygenerowany klucz tajny klienta w dzierżawie usługi Azure AD B2C.
- Zaloguj się w witrynie Azure Portal.
- Na pasku narzędzi portalu wybierz katalogi i subskrypcje.
- Ustawienia portalu | Katalogi i subskrypcje na liście Nazwa katalogu znajdź katalog Azure AD B2C.
- Wybierz pozycję Przełącz.
- W lewym górnym rogu Azure Portal wybierz pozycję Wszystkie usługi.
- Wyszukaj i wybierz pozycję Azure AD B2C.
- Na stronie Przegląd wybierz pozycję Identity Experience Framework.
- Wybierz pozycję Klucze zasad.
- Wybierz pozycję Dodaj.
- W obszarze Opcje wybierz pozycję Ręczne.
- Wprowadź nazwę klucza zasad dla klucza zasad. Prefiks
B2C_1A_
jest dołączany do nazwy klucza. - W polu Wpis tajny wprowadź zanotowany klucz tajny klienta.
- W obszarze Użycie klucza wybierz pozycję Podpis.
- Wybierz przycisk Utwórz.
Konfigurowanie usługi Asignio jako dostawcy tożsamości
Porada
Przed rozpoczęciem upewnij się, że skonfigurowano zasady Azure AD B2C. Jeśli nie, postępuj zgodnie z instrukcjami w temacie Niestandardowy pakiet startowy zasad.
Aby użytkownicy logować się przy użyciu usługi Asignio, zdefiniuj usługę Asignio jako dostawcę oświadczeń, który Azure AD B2C komunikuje się za pośrednictwem punktu końcowego. Punkt końcowy zapewnia oświadczenia, Azure AD B2C używa do weryfikowania uwierzytelniania użytkownika przy użyciu identyfikatora cyfrowego na urządzeniu.
Dodawanie Asignio jako dostawcy oświadczeń
Pobierz niestandardowe pakiety początkowe zasad 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:
Pobierz plik zip active-directory-b2c-custom-policy-starterpack lub sklonuj repozytorium:
git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
W plikach w katalogu LocalAccounts zastąp ciąg
yourtenant
nazwą dzierżawy Azure AD B2C.Otwórz plik LocalAccounts/ TrustFrameworkExtensions.xml.
Znajdź element ClaimsProviders . Jeśli go nie ma, dodaj go w elemecie głównym .
TrustFrameworkPolicy
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">00000000-0000-0000-0000-000000000000</Item> <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item> <!-- trying to add additional claim--> <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111--> <Item Key="11111111-1111-1111-1111-111111111111"></Item> <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222--> <Item Key="22222222-2222-2222-2222-222222222222"></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/11111111-1111-1111-1111-111111111111</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>
Ustaw client_id zanotowany identyfikator aplikacji Asignio.
Zaktualizuj sekcję client_secret przy użyciu utworzonego klucza zasad. Na przykład :
B2C_1A_AsignioSecret
<Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
Zapisz zmiany.
Dodawanie podróży użytkownika
Dostawca tożsamości nie znajduje się na stronach logowania.
- Jeśli masz niestandardową podróż użytkownika, przejdź do sekcji Konfigurowanie zasad jednostki uzależnionej, w przeciwnym razie skopiuj podróż użytkownika szablonu:
- W pakiecie startowym otwórz konto lokalne/TrustFrameworkBase.xml.
- Znajdź i skopiuj zawartość elementu UserJourney , który zawiera
Id=SignUpOrSignIn
element . - Otwórz plik LocalAccounts/ TrustFrameworkExtensions.xml.
- Znajdź element UserJourneys . Jeśli go nie ma, dodaj go.
- Wklej zawartość elementu UserJourney jako element podrzędny elementu UserJourneys.]
- Zmień nazwę identyfikatora podróży użytkownika. Na przykład
Id=AsignioSUSI
.
Dowiedz się więcej: Podróże użytkowników
Dodawanie dostawcy tożsamości do podróży użytkownika
Dodaj nowego dostawcę tożsamości do podróży użytkownika.
- Znajdź element kroku aranżacji, który zawiera
Type=CombinedSignInAndSignUp
element , lubType=ClaimsProviderSelection
w podróży użytkownika. Zazwyczaj jest to pierwszy krok aranżacji. Element ClaimsProviderSelections ma listę dostawcy tożsamości, za pomocą którego loguje się użytkownik. Kolejność elementów kontroluje kolejność przycisków logowania. - Dodaj element ClaimsProviderSelection XML.
- Ustaw wartość TargetClaimsExchangeId na przyjazną nazwę.
- Dodaj element ClaimsExchange .
- Ustaw identyfikator na wartość identyfikatora wymiany oświadczeń docelowych.
- Zaktualizuj wartość TechnicalProfileReferenceId na identyfikator utworzonego profilu technicznego.
Poniższy kod XML przedstawia aranżację podróży użytkownika za pomocą dostawcy 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 zasad jednostki uzależnionej
Zasady jednostki uzależnionej, na przykład SignUpSignIn.xml, określają podróż użytkownika Azure AD wykonywane przez usługę B2C.
- W jednostki uzależnionej znajdź element DefaultUserJourney .
- 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 AsignioSUSI
dla podróży użytkownika identyfikator ReferenceId jest ustawiony na AsignioSUSI
wartość :
<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>
Przekazywanie zasad niestandardowych
- Zaloguj się w witrynie Azure Portal.
- Na pasku narzędzi portalu wybierz katalogi i subskrypcje.
- Ustawienia portalu | Katalogi i subskrypcje na liście Nazwa katalogu znajdź katalog Azure AD B2C.
- Wybierz pozycję Przełącz.
- W Azure Portal wyszukaj i wybierz pozycję Azure AD B2C.
- W obszarze Zasady wybierz pozycję Struktura środowiska tożsamości.
- Wybierz pozycję Przekaż zasady niestandardowe.
- Przekaż dwa zmienione pliki zasad w następującej kolejności:
- Zasady rozszerzenia, na przykład
TrustFrameworkExtensions.xml
- Zasady jednostki uzależnionej, takie jak
SignUpOrSignin.xml
Testowanie zasad niestandardowych
- W dzierżawie usługi Azure AD B2C i w obszarze Zasady wybierz pozycję Struktura środowiska tożsamości.
- W obszarze Zasady niestandardowe wybierz pozycję AsignioSUSI.
- W polu Aplikacja wybierz zarejestrowaną aplikację internetową.
Adres URL odpowiedzi to
https://jwt.ms
. - Wybierz pozycję Uruchom teraz.
- Przeglądarka jest przekierowywana do strony logowania Asignio.
- Zostanie wyświetlony ekran logowania.
- W dolnej części wybierz pozycję 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 w celu uwierzytelnienia za pośrednictwem protokołu OTP programu SMS. Użyj linku, aby zarejestrować podpis Asignio.
- Przeglądarka jest przekierowywana do .
https://jwt.ms
Zostanie wyświetlona zawartość tokenu zwrócona przez Azure AD B2C.
Następne kroki
- Rozwiązania i szkolenia dotyczące usługi Azure Active Directory B2C
- Zadawanie pytań w witrynie Stackoverflow
- przykłady usługi Azure AD B2C
- YouTube: seria tożsamości Azure AD B2C
- 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