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

• Wykonaj kroki opisane w artykule Rozpoczynanie pracy z zasadami niestandardowymi w usłudze Azure AD B2C.

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

1. Zaloguj się do portalu Azure jako administrator zewnętrznego dostawcy tożsamości i administrator przepływu użytkowników B2C w dzierżawie Azure AD B2C.

2. Jeśli masz dostęp do wielu dzierżaw, wybierz ikonę Ustawienia w górnym menu, aby przełączyć się na dzierżawę Azure AD B2C z menu Katalogi + subskrypcje.

3. Wybierz pozycję Wszystkie usługi w lewym górnym rogu witryny Azure Portal, wyszukaj i wybierz pozycję Azure AD B2C.

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

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

6. Wybierz Dodaj.

Skonfiguruj dostawcę tożsamości

1. Wybierz typ >OpenID Connect (wersja zapoznawcza).

2. Wypełnij formularz, aby skonfigurować punkt uwierzytelniania.

   Majątek	Wartość
   Adres URL metadanych	https://authcloud.trusona.net/.well-known/openid-configuration
   ID klienta	dostępny w portalu Trusona Authentication Cloud
   Tajemnica klienta	dostępny w portalu Trusona Authentication Cloud
   Scope	Adres e-mail profilu OpenID
   Typ odpowiedzi	kod
   Tryb odpowiedzi	formularz_post

3. Kliknij przycisk OK.

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

5. Aby dokonać mapowania dostawcy tożsamości, wypełnij formularz:

   Majątek	Wartość
   Identyfikator użytkownika	Subskrypcja
   nazwa wyświetlana	nick
   Imię	given_name
   Nazwisko	nazwisko rodzinne
   Tryb odpowiedzi	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 powinieneś zobaczyć Trusona jako nowego dostawcę tożsamości OpenID Connect na liście wśród twoich IdP B2C.

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ę, wybierz wersję, a następnie wybierz pozycję Utwórz.

4. Wprowadź nazwę swojej polityki.

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

   Uwaga / Notatka

   Ponieważ Trusona jest z natury wieloczynnikowa, najlepiej pozostawić uwierzytelnianie wieloczynnikowe wyłączone.

6. Wybierz 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. Kliknij 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 wykonawczego bezpiecznej enklawy/zaufanego środowiska, które generuje oświadczenie uwierzytelniania podpisane przez klucz prywatny skojarzony z wybranym poświadczeniem. 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 tajny klucz klienta, który został wcześniej wygenerowany w kroku 1 w dzierżawie Azure AD B2C.

1. Zaloguj się do witryny Azure Portal.

2. Jeśli masz dostęp do wielu dzierżaw, wybierz ikonę Ustawienia w górnym menu, aby przełączyć się na dzierżawę Azure AD B2C z menu Katalogi + 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 ogólny wybierz pozycję Identity Experience Framework.

5. Wybierz Klucze zasad, a następnie wybierz 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 Tajny wprowadź wcześniej zarejestrowany tajny klienta.

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

10. Wybierz Utwórz.

Krok 4. Skonfiguruj chmurę uwierzytelniania Trusona jako IdP

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 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">00001111-aaaa-2222-bbbb-3333cccc4444</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: 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="00001111-aaaa-2222-bbbb-3333cccc4444"></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/00001111-aaaa-2222-bbbb-3333cccc4444</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 skonfigurowano dostawcę tożsamości, ale nie jest on jeszcze dostępny na żadnej z stron logowania. Jeśli masz własną niestandardową podróż użytkownika, przejdź do kroku 6, w przeciwnym razie utwórz duplikat istniejącej podróży użytkownika z szablonu według poniższych kroków:

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: Dodaj dostawcę tożsamości do ścieżki użytkownika

Teraz, gdy masz ścieżkę użytkownika, dodaj nowego IdP 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 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 XML ClaimsProviderSelection. Ustaw wartość TargetClaimsExchangeId na przyjazną nazwę, taką jak TrusonaTacExchange.

2. W następnym kroku aranżacji dodaj element ClaimsExchange . Ustaw identyfikator na wartość docelowego identyfikatora wymiany oświadczeń. 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 strony ufającej

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 dla ścieżki użytkownika Trusona Authentication Cloud 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. Przesyłanie zasady niestandardowej

1. Zaloguj się do witryny Azure Portal.

2. Jeśli masz dostęp do wielu dzierżaw, wybierz ikonę Ustawienia w górnym menu, aby przełączyć się na dzierżawę Azure AD B2C z menu Katalogi + subskrypcje.

3. W witrynie Azure Portal wyszukaj i wybierz pozycję Azure AD B2C.

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

5. Wybierz Załaduj zasady niestandardowe, a następnie załaduj dwa zmienione pliki zasad w następującej kolejności: zasady rozszerzenia, na przykład TrustFrameworkExtensions.xml, a następnie zasady strony zależnej, takie jak SignUpOrSignin.xml.

Krok 9: Przetestuj swoje zasady niestandardowe

1. W konfiguracji Azure AD B2C pod Zasady wybierz Identity Experience Framework.

2. W obszarze Zasady niestandardowe wybierz 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; na dole powinien znajdować się przycisk umożliwiający użycie Trusona Authentication Cloud.

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 wykonawczego bezpiecznej enklawy/zaufanego środowiska, które generuje oświadczenie uwierzytelniania podpisane przez klucz prywatny skojarzony z wybranym poświadczeniem.

7. Jeśli proces logowania zakończy się pomyślnie, przeglądarka zostanie przekierowana do https://jwt.ms, gdzie wyświetlana jest zawartość tokenu zwróconego przez Azure AD B2C.