Konfigurera Trusona Authentication Cloud med Azure Active Directory B2C

Artikel
01/26/2024

I den här exempelguiden får du lära dig hur du integrerar Azure AD B2C-autentisering med Trusona Authentication Cloud. Det är en molnbaserad tjänst som gör det möjligt för användare att autentisera med en tap-and-go-upplevelse , utan att behöva någon typ av mobilautentiseringsapp.

Fördelarna med att integrera Trusona Authentication Cloud med Azure AD B2C är:

Leverera stark autentisering med en bättre användarupplevelse
- Lyckligare användare som spenderar mer online
- Lägre attrition och övergivenhet, ökade intäkter
- Högre kvarhållning, livslängdsvärde (LTV)
Lägre kostnad för att driva verksamheten
- Minskade kontoövertaganden och kontodelning
- Minskat bedrägeri och färre manuella bedrägerianalysåtgärder
- Minskade utgifter för manuella outsourcinggranskningar
Eliminera lösenord
- Inga fler lösenordsåterställningar
- Minskade klagomål från callcenter
- Snabba, enkla, friktionsfria inloggningar med hjälp av nycklar

Förutsättningar

Du behöver följande för att komma igång:

Ett Utvärderingskonto för Trusona Authentication Cloud. Kontakta Trusona om du vill begära ett konto.
En Azure-prenumeration Om du inte har en prenumeration kan du få ett kostnadsfritt konto.
En Azure AD B2C-klientorganisation som är länkad till din Azure-prenumeration.

Slutför stegen i artikeln komma igång med anpassade principer i Azure AD B2C.

Beskrivning av scenario

Webbautentiseringsstandard – WebAuthn implementerar moderna operativsystem och webbläsare för att stödja autentisering via fingeravtryck, Windows hello eller externa FIDO-enheter som USB, Bluetooth och OTP.

I det här scenariot fungerar Trusona som identitetsprovider (IdP) för Azure AD B2C för att aktivera lösenordslös autentisering. Följande komponenter utgör lösningen:

En kombinerad inloggnings- och registreringsprincip för Azure AD B2C.
Trusona Authentication Cloud har lagts till i Azure AD B2C som en IdP.

Screenshot shows Trusona architecture diagram.

Steg	Description
1.	En användare försöker logga in på webbprogrammet via sin webbläsare.
2.	Webbprogrammet omdirigeras till Registrerings- och inloggningsprincipen för Azure AD B2C.
3.	Azure AD B2C omdirigerar användaren för autentisering till Trusona Authentication Cloud OpenID Anslut (OIDC) IdP.
4.	Användaren visas med en inloggningswebbsida som ber om deras användarnamn – vanligtvis en e-postadress.
5.	Användaren anger sin e-postadress och väljer knappen Fortsätt . Om användarens konto inte hittas i Trusona Authentication Cloud skickas ett svar till webbläsaren som initierar en Registreringsprocess för WebAuthn på enheten. Annars skickas ett svar till webbläsaren som påbörjar en WebAuthn-autentiseringsprocess.
6.	Användaren uppmanas att välja en autentiseringsuppgift som ska användas. Nyckeln är associerad med domänen för webbprogrammet eller en maskinvarusäkerhetsnyckel. När användaren har valt en autentiseringsuppgift begär operativsystemet att användaren ska använda ett biometriskt lösenord eller EN PIN-kod för att bekräfta sin identitet. Detta låser upp miljön säker enklaver/betrodd körning, vilket genererar en autentiseringskontroll signerad av den privata nyckel som är associerad med den valda autentiseringsuppgiften.
7.	Autentiseringskontrollen returneras till Trusona-molntjänsten för verifiering.
8.	När Trusona Authentication Cloud (IdP) har verifierats skapar det en OIDC ID-token och vidarebefordrar den sedan till Azure AD B2C (tjänstleverantör). Azure AD B2C verifierar tokens signatur och utfärdaren mot värdena i Trusonas OpenID-identifieringsdokument. Den här informationen konfigurerades under IdP-installationen. När det har verifierats utfärdar Azure AD B2C en OIDC-id_token (beroende på omfånget) och omdirigerar användaren tillbaka till det initierande programmet med token.
9.	Webbprogrammet (eller utvecklarbiblioteken som används för att implementera autentisering) hämtar token och verifierar äktheten för Azure AD B2C-token. Om så är fallet extraherar det anspråken och skickar dem till webbprogrammet för att använda.
10.	Vid verifiering beviljas/nekas användaren åtkomst.

Steg 1: Registrera med Trusona Authentication Cloud

Logga in på Trusona-portalen.
Välj Inställningar i den vänstra navigeringspanelen
I menyn Inställningar väljer du skjutreglaget för att aktivera OIDC.
Välj lämpliga indata och ange omdirigerings-URL:enhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp.
Generera en hemlig nyckel och kopiera nyckeln för användning i din Azure AD B2C-konfiguration.
Kommentar
1. Trusona-portalen stöder självbetjäningsregistrering. När du registrerar dig kommer du att tilldelas ett Trusona-konto med skrivskyddade rättigheter. Därefter tilldelar Trusona dig rätt konto och höjer dina rättigheter till läs-skrivning baserat på organisationens åtkomstkontrollprincip för portalanvändare.
2. Microsoft Entra-ID:ts ursprungliga domännamn används som klientomdirigeringsvärd.

Steg 2: Registrera ett webbprogram i Azure AD B2C

Innan dina program kan interagera med Azure AD B2C måste de registreras i din kundklientorganisation. Den här självstudien visar hur du registrerar ett webbprogram med hjälp av Azure-portalen. I testsyfte som den här självstudien registrerar https://jwt.msdu , ett Microsoft-ägt webbprogram som visar det avkodade innehållet i en token (innehållet i token lämnar aldrig webbläsaren). Om du vill registrera ett webbprogram i din Azure AD B2C-klientorganisation använder du vår nya enhetliga appregistreringsupplevelse.

Logga in på Azure-portalen.
Om du har åtkomst till flera klienter väljer du ikonen Inställningar på den översta menyn för att växla till din Azure AD B2C-klient från menyn Kataloger + prenumerationer.
I Azure-portalen söker du efter och väljer Azure AD B2C.
Välj Appregistreringar och välj sedan Ny registrering.
Ange ett namn för programmet. Till exempel jwt ms.
Under Kontotyper som stöds, välj Konton i valfri identitetsleverantör eller organisationskatalog (för autentisering av användare med användarflöden).
Under Omdirigerings-URI väljer du Webb och anger https://jwt.ms sedan i textrutan URL.

Omdirigerings-URI:n är den slutpunkt som auktoriseringsservern Azure AD B2C i det här fallet skickar användaren till. När du har slutfört interaktionen med användaren skickas en åtkomsttoken eller auktoriseringskod vid lyckad auktorisering. I ett produktionsprogram är det vanligtvis en offentligt tillgänglig slutpunkt där appen körs, till exempel https://contoso.com/auth-response. I testsyfte som den här självstudien kan du ställa in den på https://jwt.ms, ett Microsoft-ägt webbprogram som visar det avkodade innehållet i en token (innehållet i token lämnar aldrig webbläsaren). Under apputvecklingen kan du lägga till slutpunkten där programmet lyssnar lokalt, till exempel https://localhost:5000. Du kan lägga till och ändra omdirigerings-URI:er i dina registrerade program när som helst.

Följande begränsningar gäller för omdirigerings-URI:er:
- Svars-URL:en måste börja med schemat https, såvida du inte använder en localhost-omdirigerings-URL.
- Svars-URL:en är skiftlägeskänslig. Ärendet måste matcha fallet med URL-sökvägen för ditt program som körs. Om ditt program till exempel ingår som en del av sökvägen .../abc/response-oidcanger du .../ABC/response-oidc inte i svars-URL:en. Eftersom webbläsaren behandlar sökvägar som skiftlägeskänsliga kan cookies som är associerade med .../abc/response-oidc undantas om de omdirigeras till den skiftlägesmatchade .../ABC/response-oidc URL:en.
- Svars-URL:en bör innehålla eller exkludera det avslutande snedstrecket som programmet förväntar sig. Och kan till exempel https://contoso.com/auth-response https://contoso.com/auth-response/ behandlas som icke-matchande URL:er i ditt program.
Under Behörigheter markerar du kryssrutan Bevilja administratörsmedgivande till openid och offline_access behörigheter .
Välj Registrera.

Aktivera implicit beviljande av ID-token

Om du registrerar den här appen och konfigurerar den med https://jwt.ms/ appen för att testa ett användarflöde eller en anpassad princip måste du aktivera det implicita beviljandeflödet i appregistreringen:

I den vänstra menyn går du till Hantera och väljer Autentisering.
Under Implicit beviljande och hybridflöden markerar du kryssrutor för ID-token (används för implicita flöden och hybridflöden).
Välj Spara.

Steg 3: Konfigurera Trusona Authentication Cloud som en IdP i Azure AD B2C

Logga in på Azure Portal som global administratör för din Azure AD B2C-klientorganisationen.
Om du har åtkomst till flera klienter väljer du ikonen Inställningar på den översta menyn för att växla till din Azure AD B2C-klient från menyn Kataloger + prenumerationer.
Välj Alla tjänster på menyn högst upp till vänster i Azure-portalen och sök efter och välj Azure AD B2C.
Gå till Instrumentpanelen>Azure Active Directory B2C>Identitetsprovidrar.
Välj Identitetsprovidrar.
Markera Lägga till.

Konfigurera en IdP

Välj Identitetsprovidertyp>OpenID Anslut (förhandsversion).

Fyll i formuläret för att konfigurera IdP:

Property	Värde
Metadata-URL	`https://authcloud.trusona.net/.well-known/openid-configuration`
Klient-ID	tillgänglig på Trusona Authentication Cloud-portalen
Klienthemlighet	tillgänglig på Trusona Authentication Cloud-portalen
Definitionsområde	E-post för OpenID-profil
Svarstyp	kod
Svarsläge	form_post

Välj OK.
Välj Mappa den här identitetsproviderns anspråk.
Fyll i formuläret för att mappa IdP:t:

Property Värde

UserID under

Display name Smeknamn

Förnamn given_name

Surname family_name

Svarsläge E-post
Välj OK för att slutföra konfigurationen för ditt nya OIDC-IdP.

Property	Värde
UserID	under
Display name	Smeknamn
Förnamn	given_name
Surname	family_name
Svarsläge	E-post

Steg 4: Skapa en användarflödesprincip

Du bör nu se Trusona som en ny OpenID-Anslut identitetsprovider som anges i dina B2C-IP-adresser.

I din Azure AD B2C-klient väljer du Användarflöden under Principer.
Välj Nytt användarflöde.
Välj Registrera dig och logga in, välj en version och välj sedan Skapa.
Ange ett namn för principen.
I avsnittet Identitetsprovidrar väljer du din nyligen skapade Trusona Authentication Cloud-Identity Provider.

Kommentar

Eftersom Trusona till sin natur är multifaktor är det bäst att låta multifaktorautentiseringen vara inaktiverad.
Välj Skapa.
Under Användarattribut och anspråk väljer du Visa mer. I formuläret väljer du minst ett attribut som du angav under konfigurationen av identitetsprovidern i tidigare avsnitt.
Välj OK.

Steg 5: Testa användarflödet

Välj den princip som du skapade.
Välj Kör användarflöde och välj sedan inställningarna:

a. Program: Välj den registrerade appen, till exempel jwt ms.

b. Svars-URL: Välj omdirigerings-URL:en, till exempel https://jwt.ms.
Välja Kör användarflödet. Du bör omdirigeras till Trusona Authentication Cloud. Användaren visas med en inloggningswebbsida som ber om deras användarnamn – vanligtvis en e-postadress. Om användarens konto inte hittas i Trusona Authentication Cloud skickas ett svar till webbläsaren som initierar en Registreringsprocess för WebAuthn på enheten. Annars skickas ett svar till webbläsaren som påbörjar en WebAuthn-autentiseringsprocess. Användaren uppmanas att välja en autentiseringsuppgift som ska användas. Nyckeln är associerad med domänen för webbprogrammet eller en maskinvarusäkerhetsnyckel. När användaren har valt en autentiseringsuppgift begär operativsystemet att användaren ska använda ett biometriskt lösenord eller EN PIN-kod för att bekräfta sin identitet. Detta låser upp miljön säker enklaver/betrodd körning, vilket genererar en autentiseringskontroll signerad av den privata nyckel som är associerad med den valda autentiseringsuppgiften. Azure AD B2C verifierar Trusona-autentiseringssvaret och utfärdar en OIDC-token. Den omdirigerar användaren tillbaka till det initierande programmet, https://jwt.mstill exempel , som visar innehållet i token som returneras av Azure AD B2C.

Steg 3: Skapa principnyckel för Trusona-autentiseringsmoln

Lagra klienthemligheten som du skapade tidigare i steg 1 i din Azure AD B2C-klientorganisation.

Logga in på Azure-portalen.
Om du har åtkomst till flera klienter väljer du ikonen Inställningar på den översta menyn för att växla till din Azure AD B2C-klient från menyn Kataloger + prenumerationer.
Välj Alla tjänster på menyn högst upp till vänster i Azure-portalen och sök efter och välj Azure AD B2C.
På sidan Översikt väljer du Identity Experience Framework.
Välj Principnycklar och välj sedan Lägg till.
För Alternativ väljer du Manuell.
Ange ett Namn för principnyckeln. Exempel: TrusonaTacClientSecret Prefixet B2C_1A_ läggs automatiskt till i namnet på din nyckel.
I Hemlighet anger du din klienthemlighet som du tidigare har registrerat.
För Nyckelanvändning väljer du Signature.
Välj Skapa.

Steg 4: Konfigurera Trusona Authentication Cloud som en IdP

Dricks

Du bör ha Azure AD B2C-principen konfigurerad just nu. Om inte följer du anvisningarna om hur du konfigurerar din Azure AD B2C-klientorganisation och konfigurerar principer.

För att göra det möjligt för användare att logga in med Trusona Authentication Cloud måste du definiera Trusona som en anspråksprovider som Azure AD B2C kan kommunicera med via en slutpunkt. Slutpunkten innehåller en uppsättning anspråk som används av Azure AD B2C för att verifiera att en specifik användare har autentiserats med hjälp av en nyckel eller en maskinvarusäkerhetsnyckel som är tillgänglig på deras enhet, vilket bevisar användarens identitet.

Använd följande steg för att lägga till Trusona som anspråksprovider:

Hämta startpaketen för anpassad princip från GitHub och uppdatera sedan XML-filerna i LocalAccounts-startpaketet med ditt Azure AD B2C-klientnamn:
1. Ladda ned ZIP-filen eller klona lagringsplatsen:
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
2. I alla filer i katalogen LocalAccounts ersätter du strängen yourtenant med namnet på din Azure AD B2C-klientorganisation. Om till exempel namnet på din B2C-klient är contosoblir alla instanser av yourtenant.onmicrosoft.com .contoso.onmicrosoft.com
Öppna LocalAccounts/TrustFrameworkExtensions.xml.
Hitta elementet ClaimsProviders . Om den inte finns lägger du till den under rotelementet . TrustFrameworkPolicy
Lägg till en ny ClaimsProvider som liknar den som visas på följande sätt:

<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>

Ange client_id med Trusona Authentication Cloud-program-ID:t som du tidigare registrerade i steg 1.
Uppdatera client_secret avsnitt med namnet på principnyckeln som skapades i steg 3. Till exempel B2C_1A_TrusonaTacClientSecret:
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
```
Spara ändringarna.

Steg 5: Lägg till en användarresa

Nu har du konfigurerat IdP, men den är ännu inte tillgänglig på någon av inloggningssidorna. Om du har en egen anpassad användarresa fortsätter du till steg 6, annars skapar du en dubblett av en befintlig mallanvändarresa på följande sätt:

LocalAccounts/TrustFrameworkBase.xml Öppna filen från startpaketet.
Hitta och kopiera hela innehållet i elementet UserJourney som innehåller Id=SignUpOrSignIn.
Öppna elementet LocalAccounts/TrustFrameworkExtensions.xml och leta upp elementet UserJourneys . Om elementet inte finns lägger du till ett.
Klistra in hela innehållet i elementet UserJourney som du kopierade som underordnat elementet UserJourneys.
Byt namn på Id användarresan. Exempel: Id=TrusonaTacSUSI

Steg 6: Lägg till IdP till en användarresa

Nu när du har en användarresa lägger du till den nya IdP:n i användarresan.

Leta reda på orkestreringsstegelementet som innehåller Type=CombinedSignInAndSignUp, eller Type=ClaimsProviderSelection i användarresan. Det är vanligtvis det första orkestreringssteget. Elementet ClaimsProviderSelections innehåller en lista över IP-adresser som en användare kan logga in med. Ordningen på elementen styr ordningen på de inloggningsknappar som visas för användaren. Lägg till ett ClaimsProviderSelection XML-element. Ange värdet för TargetClaimsExchangeId till ett eget namn, till exempel TrusonaTacExchange.
I nästa orkestreringssteg lägger du till ett ClaimsExchange-element . Ange ID:t till värdet för målanspråkens utbytes-ID. Uppdatera värdet för TechnicalProfileReferenceId till ID:t för den tekniska profil som du skapade tidigare när du lade till anspråksprovidern, TrusonaTAC-OpenIdConnecttill exempel .

Följande XML visar orkestreringssteg för en användarresa med identitetsprovidern:

    <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>

Läs mer om användarresor.

Steg 7: Konfigurera principen för förlitande part

Principen för förlitande part, till exempel SignUpSignIn.xml, anger den användarresa som Azure AD B2C kör. Hitta elementet DefaultUserJourney i den förlitande parten. Uppdatera ReferenceId så att det matchar användarens rese-ID, där du lade till identitetsprovidern.

I följande exempel Trusona Authentication Cloud för användarresan är ReferenceId inställt på 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>

Steg 8: Ladda upp den anpassade principen

Logga in på Azure-portalen.
Om du har åtkomst till flera klienter väljer du ikonen Inställningar på den översta menyn för att växla till din Azure AD B2C-klient från menyn Kataloger + prenumerationer.
I Azure-portalen söker du efter och väljer Azure AD B2C.
Under Principer väljer du Identity Experience Framework.
Välj Överför anpassad princip och ladda sedan upp de två principfilerna som du ändrade i följande ordning: tilläggsprincipen, till exempel TrustFrameworkExtensions.xml, och sedan den förlitande partprincipen, till exempel SignUpOrSignin.xml.

Steg 9: Testa din anpassade princip

I din Azure AD B2C-klient väljer du Identity Experience Framework under Principer.
Under Anpassade principer väljer du TrusonaTacSUSI.
För Program väljer du det webbprogram som du tidigare registrerade som en del av den här artikelns krav. till exempel jwt ms. Svars-URL :en ska visa https://jwt.ms.
Välj kör nu. Webbläsaren bör omdirigeras till inloggningssidan för Trusona Authentication Cloud.
En inloggningsskärm visas. längst ned bör vara en knapp för att använda Trusona Authentication Cloud-autentisering .
Du bör omdirigeras till Trusona Authentication Cloud. Användaren visas med en inloggningswebbsida som ber om deras användarnamn – vanligtvis en e-postadress. Om användarens konto inte hittas i Trusona Authentication Cloud skickas ett svar till webbläsaren som initierar en Registreringsprocess för WebAuthn på enheten. Annars skickas ett svar till webbläsaren som påbörjar en WebAuthn-autentiseringsprocess. Användaren uppmanas att välja en autentiseringsuppgift som ska användas. Nyckeln är associerad med domänen för webbprogrammet eller en maskinvarusäkerhetsnyckel. När användaren har valt en autentiseringsuppgift begär operativsystemet att användaren ska använda ett biometriskt lösenord eller EN PIN-kod för att bekräfta sin identitet. Detta låser upp miljön säker enklaver/betrodd körning, vilket genererar en autentiseringskontroll signerad av den privata nyckel som är associerad med den valda autentiseringsuppgiften.
Om inloggningsprocessen lyckas omdirigeras webbläsaren till https://jwt.ms, som visar innehållet i token som returneras av Azure AD B2C.

Nästa steg

Mer information finns i följande artiklar:

Dela via