Konfigurowanie chmury uwierzytelniania Trusona za pomocą usługi Azure Active Directory B2C

W tym przykładowym samouczku dowiesz się, jak zintegrować uwierzytelnianie usługi Azure AD B2C z usługą Trusona Authentication Cloud. Jest to usługa oparta na chmurze, która umożliwia użytkownikom uwierzytelnianie za pomocą funkcji tap-and-go bez konieczności korzystania z dowolnej aplikacji do uwierzytelniania mobilnego.

Zalety integracji aplikacji Trusona Authentication Cloud z usługą Azure AD B2C obejmują:

  • Zapewnianie silnego uwierzytelniania przy użyciu lepszego środowiska użytkownika

    • Szczęśliwsi użytkownicy, którzy wydają więcej online
    • Niższe poniszczenie i porzucenie, zwiększone przychody
    • Wyższe przechowywanie, wartość okresu istnienia (LTV)
  • Niższe koszty prowadzenia działalności

    • Zmniejszone przejęcia kont i udostępnianie kont
    • Zmniejszone oszustwa i mniej ręcznych akcji analizy oszustw
    • Zmniejszone wydatki na ręczne przeglądy outsourcingu
  • Eliminowanie haseł

    • Nie ma więcej resetowania haseł
    • Zmniejszone skargi do centrum telefonicznego
    • Szybkie, proste, bezproblemowe logowania przy użyciu kluczy dostępu

Wymagania wstępne

Aby rozpocząć pracę, potrzebne będą następujące elementy:

  • Konto wersji próbnej usługi Trusona Authentication Cloud. Aby poprosić o konto, skontaktuj się z Trusona.
  • Subskrypcja Azure. Jeśli nie masz subskrypcji, możesz uzyskać bezpłatne konto.
  • Dzierżawa usługi Azure AD B2C połączona z subskrypcją platformy Azure.

Opis scenariusza

Standard uwierzytelniania sieci Web — webAuthn implementuje nowoczesne systemy operacyjne i przeglądarki do obsługi uwierzytelniania za pośrednictwem odcisku palca, funkcji Windows hello lub zewnętrznych urządzeń FIDO, takich jak USB, Bluetooth i OTP.

W tym scenariuszu trusona działa jako dostawca tożsamości dla usługi Azure AD B2C w celu włączenia uwierzytelniania bez hasła. Następujące składniki składają się na rozwiązanie:

  • Połączone zasady logowania i rejestracji w usłudze Azure AD B2C.
  • Chmura uwierzytelniania Trusona dodana do usługi Azure AD B2C jako dostawcy tożsamości.

Screenshot shows Trusona architecture diagram.

Kroki opis
1. Użytkownik próbuje zalogować się do aplikacji internetowej za pośrednictwem przeglądarki.
2. Aplikacja internetowa przekierowuje do zasad rejestracji i logowania usługi Azure AD B2C.
3. Usługa Azure AD B2C przekierowuje użytkownika do uwierzytelniania do dostawcy tożsamości usługi Trusona Authentication Cloud OpenID Połączenie (OIDC).
4. Użytkownik jest wyświetlany ze stroną internetową logowania, która prosi o nazwę użytkownika — zazwyczaj adres e-mail.
5. Użytkownik wprowadza swój adres e-mail i wybiera przycisk Kontynuuj . Jeśli konto użytkownika nie zostanie znalezione w chmurze uwierzytelniania Trusona, zostanie wysłana odpowiedź do przeglądarki, która inicjuje proces rejestracji webAuthn na urządzeniu. W przeciwnym razie do przeglądarki zostanie wysłana odpowiedź rozpoczynająca proces uwierzytelniania WebAuthn.
6. Użytkownik zostanie poproszony o wybranie poświadczenia do użycia. Klucz dostępu jest skojarzony z domeną aplikacji internetowej lub sprzętowym kluczem zabezpieczeń. Gdy użytkownik wybierze poświadczenie, system operacyjny zażąda od użytkownika użycia biometrycznego, kodu dostępu lub numeru PIN w celu potwierdzenia tożsamości. Spowoduje to odblokowanie środowiska Bezpiecznego enklawy/zaufanego wykonywania, które generuje potwierdzenie uwierzytelniania podpisane przez klucz prywatny skojarzony z wybranym poświadczeniu.
7. Potwierdzenie uwierzytelniania jest zwracane do usługi Trusona w chmurze w celu weryfikacji.
8. Po zweryfikowaniu rozwiązanie Trusona Authentication Cloud (IdP) tworzy token identyfikatora OIDC, a następnie przekazuje go do usługi Azure AD B2C (dostawca usług). Usługa Azure AD B2C weryfikuje podpis tokenu i wystawcę względem wartości w dokumencie odnajdywania OpenID trusona. Te szczegóły zostały skonfigurowane podczas konfigurowania dostawcy tożsamości. Po zweryfikowaniu usługa Azure AD B2C wystawia id_token OIDC (w zależności od zakresu) i przekierowuje użytkownika z powrotem do aplikacji inicjującej za pomocą tokenu.
9. Aplikacja internetowa (lub biblioteki deweloperów używane do implementowania uwierzytelniania) pobiera token i weryfikuje autentyczność tokenu usługi Azure AD B2C. Jeśli tak jest, wyodrębnia oświadczenia i przekazuje je do aplikacji internetowej do użycia.
10. Po weryfikacji użytkownik otrzymuje/odmawia dostępu.

Krok 1. Dołączanie przy użyciu chmury uwierzytelniania Trusona

  1. Zaloguj się do portalu Trusona.

  2. W panelu nawigacyjnym po lewej stronie wybierz pozycję Ustawienia

  3. W menu Ustawienia wybierz suwak Włącz funkcję OIDC.

  4. Wybierz odpowiednie dane wejściowe i podaj adres URLhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp przekierowania.

  5. Wygeneruj klucz tajny i skopiuj klucz do użycia w konfiguracji usługi Azure AD B2C.

    Uwaga

    1. Portal Trusona obsługuje rejestrację samoobsługową. Po zarejestrowaniu użytkownik zostanie przypisany do konta Trusona z uprawnieniami tylko do odczytu. Następnie trusona przypisze Ci odpowiednie konto i podniesie twoje prawa do odczytu i zapisu na podstawie zasad kontroli dostępu organizacji dla użytkowników portalu.
    2. Początkowa nazwa domeny identyfikatora Entra firmy Microsoft jest używana jako host przekierowania klienta.

    Screenshot shows Trusona Authentication Cloud portal settings.

Krok 2. Rejestrowanie aplikacji internetowej w usłudze Azure AD B2C

Aby aplikacje mogły wchodzić w interakcje z usługą Azure AD B2C, muszą być zarejestrowane w dzierżawie klienta. W tym samouczku pokazano, jak zarejestrować aplikację internetową przy użyciu witryny Azure Portal. Na potrzeby testowania, takie jak w tym samouczku, rejestrujesz https://jwt.msaplikację internetową firmy Microsoft, która wyświetla zdekodowany zawartość tokenu (zawartość tokenu nigdy nie opuszcza przeglądarki). Aby zarejestrować aplikację internetową w dzierżawie usługi Azure AD B2C, użyj naszego nowego ujednoliconego środowiska rejestracji 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 witrynie Azure Portal wyszukaj i wybierz pozycję Azure AD B2C.

  4. Wybierz pozycję Rejestracje aplikacji, a następnie wybierz pozycję Nowa rejestracja.

  5. Wprowadź nazwę aplikacji. Na przykład jwt ms.

  6. W obszarze Obsługiwane typy kont wybierz Konta w dowolnym dostawcy tożsamości lub katalogu organizacyjnym (do uwierzytelniania użytkowników za pomocą przepływów użytkownika).

  7. W obszarze Identyfikator URI przekierowania wybierz pozycję Sieć Web, a następnie wprowadź ciąg https://jwt.ms w polu tekstowym Adres URL.

    Identyfikator URI przekierowania to punkt końcowy, do którego serwer autoryzacji, usługa Azure AD B2C w tym przypadku wysyła użytkownika do. Po zakończeniu interakcji z użytkownikiem token dostępu lub kod autoryzacji jest wysyłany po pomyślnym uwierzytelnieniu. W aplikacji produkcyjnej zazwyczaj jest to publicznie dostępny punkt końcowy, w którym aplikacja jest uruchomiona, na przykład https://contoso.com/auth-response. W celach testowych, takich jak w tym samouczku, można ustawić ją na , należącą do https://jwt.msfirmy Microsoft aplikację internetową, która wyświetla zdekodowana zawartość tokenu (zawartość tokenu nigdy nie opuszcza przeglądarki). Podczas tworzenia aplikacji możesz dodać punkt końcowy, w którym aplikacja nasłuchuje lokalnie, na przykład https://localhost:5000. W dowolnym momencie możesz dodawać i modyfikować identyfikatory URI przekierowania w zarejestrowanych aplikacjach.

    Następujące ograniczenia dotyczą identyfikatorów URI przekierowania:

    • Adres URL odpowiedzi musi zaczynać się od schematu https, chyba że używasz adresu URL przekierowania localhost.
    • W adresie URL odpowiedzi jest uwzględniana wielkość liter. Jego wielkość liter musi być zgodna ze wielkością ścieżki adresu URL uruchomionej aplikacji. Jeśli na przykład aplikacja zawiera jako część ścieżki .../abc/response-oidc, nie należy określać .../ABC/response-oidc w adresie URL odpowiedzi. Ponieważ przeglądarka internetowa traktuje ścieżki jako wrażliwe na wielkość liter, pliki cookie skojarzone z usługą .../abc/response-oidc mogą zostać wykluczone w przypadku przekierowania do niezgodnego .../ABC/response-oidc adresu URL.
    • Adres URL odpowiedzi powinien zawierać lub wykluczyć ukośnik końcowy w miarę oczekiwania aplikacji. Na przykład https://contoso.com/auth-response i https://contoso.com/auth-response/ może być traktowana jako niezgodne adresy URL w aplikacji.
  8. W obszarze Uprawnienia zaznacz pole wyboru Udziel zgody administratora na otwieranie i offline_access uprawnienia .

  9. Wybierz pozycję Zarejestruj.

Włącz niejawne udzielanie tokenu identyfikatora

Jeśli zarejestrujesz tę aplikację i skonfigurujesz ją przy https://jwt.ms/ użyciu aplikacji na potrzeby testowania przepływu użytkownika lub zasad niestandardowych, musisz włączyć niejawny przepływ udzielania w rejestracji aplikacji:

  1. W menu po lewej stronie w obszarze Zarządzanie wybierz pozycję Uwierzytelnianie.

  2. W obszarze Niejawne udzielanie i przepływy hybrydowe zaznacz pola wyboru Tokeny identyfikatorów (używane w przypadku przepływów niejawnych i hybrydowych).

  3. Wybierz pozycję Zapisz.

Krok 3. Konfigurowanie chmury uwierzytelniania Trusona jako dostawcy tożsamości w usłudze Azure AD B2C

  1. Zaloguj się w witrynie Azure Portal jako administrator globalny dzierżawy usługi Azure AD B2C.

  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 usługę Azure AD B2C.

  4. Przejdź do pozycji Pulpit nawigacyjny>Dostawcy tożsamości usługi Azure Active Directory B2C.>

  5. Wybierz pozycję Dostawcy tożsamości.

  6. Wybierz pozycję Dodaj.

Konfigurowanie dostawcy tożsamości

  1. Wybierz pozycję Typ>dostawcy tożsamości OpenID Połączenie (wersja zapoznawcza).

  2. Wypełnij formularz, aby skonfigurować dostawcę tożsamości:

    Właściwości Wartość
    Adres URL metadanych https://authcloud.trusona.net/.well-known/openid-configuration
    Client ID dostępny w portalu Trusona Authentication Cloud
    Klucz tajny klienta dostępny w portalu Trusona Authentication Cloud
    Scope Adres e-mail profilu OpenID
    Typ odpowiedzi code
    Tryb odpowiedzi form_post
  3. Wybierz przycisk OK.

  4. Wybierz pozycję Mapuj oświadczenia tego dostawcy tożsamości.

  5. Wypełnij formularz, aby zamapować dostawcę tożsamości:

    Właściwości Wartość
    UserID Sub
    Display name Nick
    Imię given_name
    Surname family_name
    Tryb odpowiedzi adres e-mail
  6. Wybierz przycisk OK , aby ukończyć konfigurację nowego dostawcy tożsamości OIDC.

Krok 4. Tworzenie zasad przepływu użytkownika

Teraz narzędzie Trusona powinno być widoczne jako nowy identyfikator OpenID Połączenie Identity Provider na liście w ramach dostawców tożsamości B2C.

  1. W dzierżawie usługi Azure AD B2C w obszarze Zasady wybierz pozycję Przepływy użytkownika.

  2. Wybierz pozycję Nowy przepływ użytkownika.

  3. Wybierz pozycję Zarejestruj się i zaloguj się, wybierz wersję, a następnie wybierz pozycję Utwórz.

  4. Wprowadź nazwę zasad.

  5. W sekcji Dostawcy tożsamości wybierz nowo utworzonego dostawcę usługi Trusona Authentication Cloud-Identity Provider.

    Uwaga

    Ponieważ trusona jest z natury wieloskładnikowa, najlepiej pozostawić uwierzytelnianie wieloskładnikowe wyłączone.

  6. Wybierz pozycję Utwórz.

  7. W obszarze Atrybuty użytkownika i oświadczenia wybierz pozycję Pokaż więcej. W formularzu wybierz co najmniej jeden atrybut określony podczas konfigurowania dostawcy tożsamości we wcześniejszej sekcji.

  8. Wybierz przycisk OK.

Krok 5. Testowanie przepływu użytkownika

  1. Wybierz utworzone zasady.

  2. Wybierz pozycję Uruchom przepływ użytkownika, a następnie wybierz ustawienia:

    a. Aplikacja: wybierz zarejestrowaną aplikację, na przykład jwt ms.

    b. Adres URL odpowiedzi: wybierz adres URL przekierowania, na przykład https://jwt.ms.

  3. Wybierz Uruchom przepływ użytkownika. Powinno nastąpić przekierowanie do chmury uwierzytelniania Trusona. Użytkownik jest wyświetlany ze stroną internetową logowania, która prosi o nazwę użytkownika — zazwyczaj adres e-mail. Jeśli konto użytkownika nie zostanie znalezione w chmurze uwierzytelniania Trusona, odpowiedź zostanie wysłana do przeglądarki, która inicjuje proces rejestracji webAuthn na urządzeniu. W przeciwnym razie do przeglądarki zostanie wysłana odpowiedź rozpoczynająca proces uwierzytelniania WebAuthn. Użytkownik zostanie poproszony o wybranie poświadczenia do użycia. Klucz dostępu jest skojarzony z domeną aplikacji internetowej lub sprzętowym kluczem zabezpieczeń. Gdy użytkownik wybierze poświadczenie, system operacyjny zażąda od użytkownika użycia biometrycznego, kodu dostępu lub numeru PIN w celu potwierdzenia tożsamości. Spowoduje to odblokowanie środowiska Bezpiecznego enklawy/zaufanego wykonywania, które generuje potwierdzenie uwierzytelniania podpisane przez klucz prywatny skojarzony z wybranym poświadczeniu. Usługa Azure AD B2C weryfikuje odpowiedź uwierzytelniania trusona i wystawia token OIDC. Przekierowuje użytkownika z powrotem do inicjującej aplikacji, na przykład https://jwt.ms, która wyświetla zawartość tokenu zwróconego przez usługę Azure AD B2C.

Krok 3. Tworzenie klucza zasad uwierzytelniania trusona w chmurze

Zapisz wpis tajny klienta, który został wcześniej wygenerowany w kroku 1 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 usługę 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ę Ręczne.

  7. Wprowadź nazwę klucza zasad. Na przykład TrusonaTacClientSecret. Prefiks B2C_1A_ jest dodawany automatycznie do nazwy klucza.

  8. W obszarze Wpis tajny wprowadź wcześniej zarejestrowany wpis tajny klienta.

  9. W obszarze Użycie klucza wybierz pozycję Signature.

  10. Wybierz pozycję Utwórz.

Krok 4. Konfigurowanie chmury uwierzytelniania Trusona jako dostawcy tożsamości

Napiwek

W tym momencie należy skonfigurować zasady usługi Azure AD B2C. Jeśli nie, postępuj zgodnie z instrukcjami dotyczącymi konfigurowania dzierżawy usługi Azure AD B2C i konfigurowania zasad.

Aby umożliwić użytkownikom logowanie się przy użyciu usługi Trusona Authentication Cloud, należy zdefiniować narzędzie Trusona jako dostawca oświadczeń, z którym usługa Azure AD B2C może komunikować się za pośrednictwem punktu końcowego. Punkt końcowy udostępnia zestaw oświadczeń używanych przez usługę Azure AD B2C do weryfikowania, czy określony użytkownik uwierzytelnił się przy użyciu klucza dostępu lub sprzętowego klucza zabezpieczeń dostępnego na urządzeniu, udowadniając tożsamość użytkownika.

Aby dodać program Trusona jako dostawca oświadczeń, wykonaj następujące czynności:

  1. 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 lub sklonuj repozytorium:

          git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
      
    2. We wszystkich plikach w katalogu LocalAccounts zastąp ciąg yourtenant nazwą dzierżawy usługi Azure AD B2C. Jeśli na przykład nazwa dzierżawy B2C to contoso, wszystkie wystąpienia yourtenant.onmicrosoft.com stają się contoso.onmicrosoft.com.

  2. Otwórz klasę LocalAccounts/TrustFrameworkExtensions.xml.

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

  4. Dodaj nowy obiekt ClaimsProvider podobny do przedstawionego w następujący sposób:

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</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="11111111-1111-1111-1111-111111111111"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
        <!-- The commented key 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>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </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://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>
  1. Ustaw client_id przy użyciu identyfikatora aplikacji Trusona Authentication Cloud zarejestrowanego wcześniej w kroku 1.

  2. Zaktualizuj sekcję client_secret o nazwę klucza zasad utworzonego w kroku 3. Na przykład : B2C_1A_TrusonaTacClientSecret

    <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
    
  3. Zapisz zmiany.

Krok 5. Dodawanie podróży użytkownika

Na tym etapie skonfigurowaliśmy dostawcę tożsamości, ale nie jest jeszcze dostępny na żadnej ze stron logowania. Jeśli masz własną niestandardową podróż użytkownika do kroku 6, w przeciwnym razie utwórz duplikat istniejącej podróży użytkownika szablonu w następujący sposób:

  1. LocalAccounts/TrustFrameworkBase.xml Otwórz plik z pakietu startowego.

  2. Znajdź i skopiuj całą zawartość elementu UserJourney , który zawiera Id=SignUpOrSignInelement .

  3. Otwórz element LocalAccounts/TrustFrameworkExtensions.xml i znajdź element UserJourneys . Jeśli element nie istnieje, dodaj go.

  4. Wklej całą zawartość elementu UserJourney skopiowaną jako element podrzędny elementu UserJourneys.

  5. Id Zmień nazwę podróży użytkownika. Na przykład Id=TrusonaTacSUSI.

Krok 6. Dodawanie dostawcy tożsamości do podróży użytkownika

Teraz, gdy masz podróż użytkownika, dodaj nowego dostawcę tożsamości do podróży użytkownika.

  1. Znajdź element kroku aranżacji, który zawiera Type=CombinedSignInAndSignUpelement , lub Type=ClaimsProviderSelection w podróży użytkownika. Zazwyczaj jest to pierwszy krok aranżacji. Element ClaimsProviderSelections zawiera listę dostawców tożsamości, za pomocą których użytkownik może się zalogować. Kolejność elementów kontroluje kolejność przycisków logowania przedstawionych użytkownikowi. Dodaj element ClaimsProviderSelection XML. Ustaw wartość TargetClaimsExchangeId na przyjazną nazwę, taką jak TrusonaTacExchange.

  2. W następnym kroku aranżacji dodaj element ClaimsExchange . Ustaw identyfikator na wartość identyfikatora wymiany oświadczeń docelowych. Zaktualizuj wartość TechnicalProfileReferenceId na identyfikator utworzonego wcześniej profilu technicznego podczas dodawania dostawcy oświadczeń, na przykład TrusonaTAC-OpenIdConnect.

Poniższy kod XML przedstawia kroki aranżacji podróży użytkownika z dostawcą tożsamości:

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <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="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <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 (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>

Dowiedz się więcej o podróżach użytkowników.

Krok 7. Konfigurowanie zasad jednostki uzależnionej

Zasady jednostki uzależnionej, na przykład SignUpSignIn.xml, określają podróż użytkownika, którą wykonuje usługa Azure AD B2C. Znajdź element DefaultUserJourney w ramach jednostki uzależnionej. 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 Trusona Authentication Cloud dla podróży użytkownika identyfikator ReferenceId jest ustawiony na :TrusonaTacSUSI

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <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>

Krok 8. Przekazywanie zasad niestandardowych

  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 witrynie Azure Portal wyszukaj i wybierz pozycję Azure AD B2C.

  4. W obszarze Zasady wybierz pozycję Identity Experience Framework.

  5. Wybierz pozycję Przekaż zasady niestandardowe, a następnie przekaż dwa zmienione pliki zasad w następującej kolejności: zasady rozszerzenia, na przykład TrustFrameworkExtensions.xml, a następnie zasady jednostki uzależnionej, takie jak SignUpOrSignin.xml.

Krok 9. Testowanie zasad niestandardowych

  1. W dzierżawie usługi Azure AD B2C w obszarze Zasady wybierz pozycję Identity Experience Framework.

  2. W obszarze Zasady niestandardowe wybierz pozycję TrusonaTacSUSI.

  3. W polu Aplikacja wybierz aplikację internetową, która została wcześniej zarejestrowana w ramach wymagań wstępnych tego artykułu. na przykład jwt ms. Adres URL odpowiedzi powinien zawierać wartość https://jwt.ms.

  4. Wybierz opcję Uruchom teraz. Przeglądarka powinna zostać przekierowana do strony logowania do chmury uwierzytelniania Trusona.

  5. Zostanie wyświetlony ekran logowania; w dolnej części powinien być przyciskiem umożliwiającym użycie uwierzytelniania trusona w chmurze .

  6. Powinno nastąpić przekierowanie do chmury uwierzytelniania Trusona. Użytkownik jest wyświetlany ze stroną internetową logowania, która prosi o nazwę użytkownika — zazwyczaj adres e-mail. Jeśli konto użytkownika nie zostanie znalezione w chmurze uwierzytelniania Trusona, zostanie wysłana odpowiedź do przeglądarki, która inicjuje proces rejestracji webAuthn na urządzeniu. W przeciwnym razie do przeglądarki zostanie wysłana odpowiedź rozpoczynająca proces uwierzytelniania WebAuthn. Użytkownik zostanie poproszony o wybranie poświadczenia do użycia. Klucz dostępu jest skojarzony z domeną aplikacji internetowej lub sprzętowym kluczem zabezpieczeń. Gdy użytkownik wybierze poświadczenie, system operacyjny zażąda od użytkownika użycia biometrycznego, kodu dostępu lub numeru PIN w celu potwierdzenia tożsamości. Spowoduje to odblokowanie środowiska Bezpiecznego enklawy/zaufanego wykonywania, które generuje potwierdzenie uwierzytelniania podpisane przez klucz prywatny skojarzony z wybranym poświadczeniu.

  7. Jeśli proces logowania zakończy się pomyślnie, przeglądarka zostanie przekierowana do https://jwt.msusługi , która wyświetla zawartość tokenu zwróconego przez usługę Azure AD B2C.

Następne kroki

Aby uzyskać dodatkowe informacje, zapoznaj się z następującymi artykułami: