Konfigurace cloudu ověřování Trusona pomocí Azure Active Directory B2C

Článek
01/26/2024

V tomto ukázkovém kurzu se dozvíte, jak integrovat ověřování Azure AD B2C s cloudem Trusona Authentication Cloud. Jedná se o cloudovou službu, která uživatelům umožňuje ověřování pomocí funkce klepnutí a práce , aniž by museli používat jakoukoli mobilní ověřovací aplikaci.

Mezi výhody integrace cloudu Trusona Authentication s Azure AD B2C patří:

Zajištění silného ověřování s lepším uživatelským prostředím
- Šťastnější uživatelé, kteří tráví více online
- Nižší výnosy a opuštění, vyšší výnosy
- Vyšší doba uchování, hodnota životnosti (LTV)
Nižší náklady na provoz firmy
- Omezené převzetí účtů a sdílení účtů
- Omezené podvody a méně akcí ručně prováděných analýzou podvodů
- Snížené výdaje na externí ruční recenze
Eliminace hesel
- Žádné další resetování hesla
- Omezené stížnosti na call center
- Rychlá, jednoduchá, beztřebná přihlášení pomocí přístupových klíčů

Předpoklady

Na začátek budete potřebovat:

Zkušební účet Trusona Authentication Cloud Pokud chcete požádat o účet, obraťte se na Trusona.
Předplatné Azure. Pokud předplatné nemáte, můžete získat bezplatný účet.
Tenant Azure AD B2C, který je propojený s vaším předplatným Azure.

Dokončete kroky v článku začínáme s vlastními zásadami v Azure AD B2C.

Popis scénáře

Standard webového ověřování – WebAuthn implementuje moderní operační systémy a prohlížeče, které podporují ověřování pomocí otisku prstu, Windows Hello nebo externích zařízení FIDO, jako jsou USB, Bluetooth a OTP.

V tomto scénáři Trusona funguje jako zprostředkovatel identity (IDP) pro Azure AD B2C, který umožňuje ověřování bez hesla. Řešení tvoří následující komponenty:

Kombinované zásady přihlašování a registrace v Azure AD B2C.
Cloud ověřování Trusona přidaný do Azure AD B2C jako zprostředkovatele identity

Screenshot shows Trusona architecture diagram.

Kroky	Popis
1.	Uživatel se pokusí přihlásit k webové aplikaci prostřednictvím prohlížeče.
2.	Webová aplikace přesměruje na zásady registrace a přihlašování azure AD B2C.
3.	Azure AD B2C přesměruje uživatele k ověřování na zprostředkovatele OpenID cloudu Trusona Authentication Připojení (OIDC).
4.	Uživateli se zobrazí přihlašovací webová stránka, která požádá o uživatelské jméno – obvykle e-mailovou adresu.
5.	Uživatel zadá svoji e-mailovou adresu a vybere tlačítko Pokračovat . Pokud se účet uživatele v cloudu Trusona Authentication Cloud nenajde, odešle se do prohlížeče odpověď, která na zařízení zahájí proces registrace WebAuthn. V opačném případě se do prohlížeče odešle odpověď, která zahájí proces ověřování WebAuthn.
6.	Uživateli se zobrazí výzva k výběru přihlašovacích údajů, které se mají použít. Klíč je přidružený k doméně webové aplikace nebo klíče hardwarového zabezpečení. Jakmile uživatel vybere přihlašovací údaje, operační systém požádá uživatele o ověření identity pomocí biometrického kódu, hesla nebo KÓDU PIN. Tím se odemkne zabezpečené prostředí enklávy nebo důvěryhodného spouštění, které generuje ověřovací kontrolní výraz podepsaný privátním klíčem přidruženým k vybraným přihlašovacím údajům.
7.	Ověřovací kontrolní výraz se vrátí do cloudové služby Trusona k ověření.
8.	Po ověření vytvoří cloud Trusona Authentication Cloud (IdP) token ID OIDC a pak ho předá službě Azure AD B2C (poskytovatel služeb). Azure AD B2C ověří podpis tokenu a vystavitele proti hodnotám v dokumentu zjišťování OpenID trusona. Tyto podrobnosti byly nakonfigurovány během instalace zprostředkovatele identity. Po ověření Azure AD B2C vydá id_token OIDC (v závislosti na rozsahu) a přesměruje uživatele zpět na iniciační aplikaci pomocí tokenu.
9.	Webová aplikace (nebo knihovny vývojářů, které používá k implementaci ověřování), načte token a ověří pravost tokenu Azure AD B2C. V takovém případě extrahuje deklarace identity a předá je do webové aplikace, kterou bude využívat.
10.	Po ověření se uživateli udělí nebo odepře přístup.

Krok 1: Onboarding s cloudem Trusona Authentication Cloud

Přihlaste se k portálu Trusona.
Na levém navigačním panelu vyberte Nastavení
V nabídce Nastavení vyberte posuvník pro povolení OIDC.
Vyberte příslušné vstupy a zadejte adresu URLhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp pro přesměrování.
Vygenerujte tajný klíč a zkopírujte klíč pro použití v nastavení Azure AD B2C.
Poznámka:
1. Portál Trusona podporuje samoobslužnou registraci. Po registraci se vám přiřadí účet Trusona s právy jen pro čtení. Trusona vám pak přiřadí správný účet a zvýší vaše práva na čtení i zápis na základě zásad řízení přístupu vaší organizace pro uživatele portálu.
2. Počáteční název domény id Microsoft Entra se používá jako hostitel přesměrování klienta.

Krok 2: Registrace webové aplikace v Azure AD B2C

Aby vaše aplikace mohly pracovat s Azure AD B2C, musí být zaregistrované ve vašem zákaznickém tenantovi. V tomto kurzu se dozvíte, jak zaregistrovat webovou aplikaci pomocí webu Azure Portal. Pro účely testování, jako je tento kurz, registrujete https://jwt.mswebovou aplikaci vlastněnou Microsoftem, která zobrazuje dekódovaný obsah tokenu (obsah tokenu nikdy neopustí váš prohlížeč). Pokud chcete zaregistrovat webovou aplikaci ve vašem tenantovi Azure AD B2C, použijte nové jednotné prostředí registrace aplikací.

Přihlaste se k portálu Azure.
Pokud máte přístup k více tenantům, v horní nabídce vyberte ikonu Nastavení a v nabídce Adresáře a předplatná přepněte do svého tenanta Azure AD B2C.
Na webu Azure Portal vyhledejte a vyberte Azure AD B2C.
Vyberte Registrace aplikací a pak vyberte Nová registrace.
Zadejte název aplikace. Například jwt ms.
V sekci Podporované typy účtů vyberte Účty u libovolného zprostředkovatele identity nebo organizačního adresáře (pro ověřování uživatelů pomocí toků uživatelů).
V části Identifikátor URI pro přesměrování vyberte Web a zadejte https://jwt.ms do textového pole adresa URL.

Identifikátor URI přesměrování je koncový bod, do kterého autorizační server Azure AD B2C v tomto případě odešle uživatele. Po dokončení interakce s uživatelem se po úspěšné autorizaci odešle přístupový token nebo autorizační kód. V produkční aplikaci se obvykle jedná o veřejně přístupný koncový bod, ve kterém je vaše aplikace spuštěná, například https://contoso.com/auth-response. Pro účely testování, jako je tento kurz, můžete ho nastavit na https://jwt.mswebovou aplikaci vlastněnou Microsoftem, která zobrazuje dekódovaný obsah tokenu (obsah tokenu nikdy neopustí váš prohlížeč). Během vývoje aplikací můžete přidat koncový bod, ve kterém vaše aplikace naslouchá místně, například https://localhost:5000. Identifikátory URI pro přesměrování můžete v registrovaných aplikacích kdykoli přidávat a upravovat.

Pro identifikátory URI přesměrování platí následující omezení:
- Adresa URL odpovědi musí začínat schématem https, pokud nepoužíváte adresu URL přesměrování místního hostitele.
- V adrese URL odpovědi se rozlišují malá a velká písmena. Jeho případ se musí shodovat s případem cesty URL spuštěné aplikace. Pokud vaše aplikace například obsahuje jako součást cesty .../abc/response-oidc, nezadávejte .../ABC/response-oidc v adrese URL odpovědi. Vzhledem k tomu, že webový prohlížeč pracuje s cestami jako s rozlišováním velkých a malých písmen, mohou být soubory cookie přidružené .../abc/response-oidc k souborům cookie vyloučeny, pokud jsou přesměrovány na neodpovídající .../ABC/response-oidc adresu URL.
- Adresa URL odpovědi by měla obsahovat nebo vyloučit koncové lomítko podle očekávání vaší aplikace. Například a https://contoso.com/auth-response/ může se jednat o adresy URL, https://contoso.com/auth-response které nejsou v aplikaci shodné.
V části Oprávnění zaškrtněte políčko Udělit správci souhlas s openid a offline_access oprávnění.
Vyberte Zaregistrovat.

Povolení implicitního udělení tokenu ID

Pokud tuto aplikaci zaregistrujete a nakonfigurujete ji v https://jwt.ms/ aplikaci pro testování toku uživatele nebo vlastních zásad, musíte v registraci aplikace povolit implicitní tok udělení:

V nabídce vlevo v části Spravovat vyberte Ověřování.
V části Implicitní udělení a hybridní toky zaškrtněte políčka Tokeny ID (používané pro implicitní a hybridní toky).
Zvolte Uložit.

Krok 3: Konfigurace cloudu trusona authentication jako zprostředkovatele identity v Azure AD B2C

Přihlaste se k webu Azure Portal jako globální správce vašeho tenanta Azure AD B2C.
Pokud máte přístup k více tenantům, v horní nabídce vyberte ikonu Nastavení a v nabídce Adresáře a předplatná přepněte do svého tenanta Azure AD B2C.
Zvolte Všechny služby v levém horním rohu portálu Azure Portal a vyhledejte a vyberte Azure AD B2C.
Přejděte na řídicí panel>Azure Active Directory B2C>Zprostředkovatele identity.
Vyberte zprostředkovatele identity.
Vyberte Přidat.

Konfigurace zprostředkovatele identity

Vyberte Typ>zprostředkovatele identity OpenID Připojení (Preview).

Vyplňte formulář a nastavte zprostředkovatele identity:

Vlastnost	Hodnota
Adresa URL metadat	`https://authcloud.trusona.net/.well-known/openid-configuration`
ID klienta	k dispozici na portálu Trusona Authentication Cloud
Tajný klíč klienta	k dispozici na portálu Trusona Authentication Cloud
Obor	E-mail profilu OpenID
Typ odpovědi	code
Režim odpovědi	form_post

Vyberte OK.
Vyberte Namapovat deklarace identity tohoto zprostředkovatele identity.
Vyplňte formulář pro mapování zprostředkovatele identity:

Vlastnost Hodnota

UserID předmět

Zobrazované jméno Přezdívka

Křestní jméno given_name

Surname family_name

Režim odpovědi E-mail
Výběrem možnosti OK dokončete nastavení nového zprostředkovatele identity OIDC.

Vlastnost	Hodnota
UserID	předmět
Zobrazované jméno	Přezdívka
Křestní jméno	given_name
Surname	family_name
Režim odpovědi	E-mail

Krok 4: Vytvoření zásady toku uživatele

Teď byste měli vidět Trusona jako nový zprostředkovatel identity OpenID Připojení uvedený v ip adresách B2C.

V tenantovi Azure AD B2C v části Zásady vyberte Toky uživatelů.
Vyberte Nový tok uživatele.
Vyberte Zaregistrovat se a přihlásit se, vyberte verzi a pak vyberte Vytvořit.
Zadejte název zásady.
V části Zprostředkovatelé identity vyberte nově vytvořeného zprostředkovatele cloudových identit Trusona Authentication.

Poznámka:

Vzhledem k tomu, že Trusona je ze své podstaty vícefaktorové, je nejlepší nechat vícefaktorové ověřování zakázané.
Vyberte Vytvořit.
V části Atributy uživatele a deklarace identity zvolte Zobrazit více. Ve formuláři vyberte alespoň jeden atribut, který jste zadali při nastavování zprostředkovatele identity v předchozí části.
Vyberte OK.

Krok 5: Testování toku uživatele

Vyberte zásadu, kterou jste vytvořili.
Vyberte Spustit tok uživatele a pak vyberte nastavení:

a. Aplikace: Vyberte registrovanou aplikaci, například jwt ms.

b. Adresa URL odpovědi: Vyberte adresu URL pro přesměrování, https://jwt.msnapříklad .
Vyberte Spustit tok uživatele. Měli byste být přesměrováni do cloudu Trusona Authentication Cloud. Uživateli se zobrazí přihlašovací webová stránka, která požádá o uživatelské jméno – obvykle e-mailovou adresu. Pokud se účet uživatele v cloudu Trusona Authentication Cloud nenajde, odešle se do prohlížeče odpověď, která na zařízení zahájí proces registrace WebAuthn. V opačném případě se do prohlížeče odešle odpověď, která zahájí proces ověřování WebAuthn. Uživateli se zobrazí výzva k výběru přihlašovacích údajů, které se mají použít. Klíč je přidružený k doméně webové aplikace nebo klíče hardwarového zabezpečení. Jakmile uživatel vybere přihlašovací údaje, operační systém požádá uživatele o ověření identity pomocí biometrického kódu, hesla nebo KÓDU PIN. Tím se odemkne zabezpečené prostředí enklávy nebo důvěryhodného spouštění, které generuje ověřovací kontrolní výraz podepsaný privátním klíčem přidruženým k vybraným přihlašovacím údajům. Azure AD B2C ověřuje odpověď na ověřování Trusona a vydává token OIDC. Přesměruje uživatele zpět do iniciační aplikace, https://jwt.msnapříklad , která zobrazí obsah tokenu vráceného Službou Azure AD B2C.

Krok 3: Vytvoření klíče zásad cloudu ověřování Trusona

Uložte tajný klíč klienta, který jste dříve vygenerovali v kroku 1 ve svém tenantovi Azure AD B2C.

Přihlaste se k portálu Azure.
Pokud máte přístup k více tenantům, v horní nabídce vyberte ikonu Nastavení a v nabídce Adresáře a předplatná přepněte do svého tenanta Azure AD B2C.
V levém horním rohu webu Azure Portal zvolte Všechny služby a pak vyhledejte a vyberte Azure AD B2C.
Na stránce Přehled vyberte rozhraní Identity Experience Framework.
Vyberte Klíče zásad a pak vyberte Přidat.
V nabídce Možnosti zvolte Ručně.
Zadejte název klíče zásady. Například, TrusonaTacClientSecret. Předpona B2C_1A_ se automaticky přidá do názvu klíče.
V tajném kódu zadejte tajný klíč klienta, který jste předtím zaznamenali.
V případě použití klíče vyberte Signature.
Vyberte Vytvořit.

Krok 4: Konfigurace cloudu ověřování Trusona jako zprostředkovatele identity

Tip

V tuto chvíli byste měli mít nakonfigurované zásady Azure AD B2C. Pokud ne, postupujte podle pokynů k nastavení tenanta Azure AD B2C a konfiguraci zásad.

Pokud chcete uživatelům umožnit přihlášení pomocí cloudu Trusona Authentication Cloud, musíte trusona definovat jako zprostředkovatele deklarací identity, se kterým může Azure AD B2C komunikovat prostřednictvím koncového bodu. Koncový bod poskytuje sadu deklarací identity, které Azure AD B2C používá k ověření, že se konkrétní uživatel ověřil pomocí klíče nebo klíče hardwarového zabezpečení, který je k dispozici na svém zařízení a prokáže identitu uživatele.

Pomocí následujících kroků přidejte Trusona jako zprostředkovatele deklarací identity:

Získejte úvodní balíčky vlastních zásad z GitHubu a pak aktualizujte soubory XML v úvodním balíčku LocalAccounts názvem tenanta Azure AD B2C:
1. Stáhněte si soubor .zip nebo naklonujte úložiště:
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
2. Ve všech souborech v adresáři LocalAccounts nahraďte řetězec yourtenant názvem vašeho tenanta Azure AD B2C. Pokud je například název vašeho tenanta contosoB2C , všechny instance yourtenant.onmicrosoft.com stát contoso.onmicrosoft.comse .
Otevřete třídu LocalAccounts/TrustFrameworkExtensions.xml.
Vyhledejte element ClaimsProviders . Pokud neexistuje, přidejte ho pod kořenový prvek . TrustFrameworkPolicy
Přidejte nový ClaimsProvider podobný té, která je zobrazena takto:

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

Nastavte client_id pomocí ID aplikace Trusona Authentication Cloud, které jste si dříve poznamenali v kroku 1.
Aktualizujte oddíl client_secret názvem klíče zásad vytvořeného v kroku 3. Příklad: B2C_1A_TrusonaTacClientSecret
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
```
Uložte změny.

Krok 5: Přidání cesty uživatele

V tuto chvíli jste nastavili zprostředkovatele identity, ale zatím není k dispozici na žádné přihlašovací stránce. Pokud máte vlastní cestu uživatele, pokračujte krokem 6, jinak vytvořte duplikát existující cesty uživatele šablony následujícím způsobem:

LocalAccounts/TrustFrameworkBase.xml Otevřete soubor z úvodní sady.
Najděte a zkopírujte celý obsah prvku UserJourney , který obsahuje Id=SignUpOrSignIn.
LocalAccounts/TrustFrameworkExtensions.xml Otevřete a najděte prvek UserJourneys. Pokud prvek neexistuje, přidejte ho.
Vložte celý obsah elementu UserJourney, který jste zkopírovali jako podřízený prvek UserJourneys.
Id Přejmenujte cestu uživatele. Například, Id=TrusonaTacSUSI.

Krok 6: Přidání zprostředkovatele identity do cesty uživatele

Teď, když máte cestu uživatele, přidejte do cesty uživatele nový zprostředkovatele identity.

Najděte prvek kroku orchestrace, který zahrnuje Type=CombinedSignInAndSignUpnebo Type=ClaimsProviderSelection na cestě uživatelem. Obvykle se jedná o první krok orchestrace. Element ClaimsProviderSelections obsahuje seznam zprostředkovatele identity, pomocí kterého se uživatel může přihlásit. Pořadí prvků řídí pořadí tlačítek pro přihlášení, která jsou uživateli prezentována. Přidejte element XML ClaimsProviderSelection. Nastavte hodnotu TargetClaimsExchangeId na popisný název, například TrusonaTacExchange.
V dalším kroku orchestrace přidejte element ClaimsExchange . Nastavte ID na hodnotu ID cílové výměny deklarací identity. Aktualizujte hodnotu TechnicalProfileReferenceId na ID technického profilu, který jste vytvořili dříve při přidávání zprostředkovatele deklarací identity, TrusonaTAC-OpenIdConnectnapříklad .

Následující kód XML ukazuje kroky orchestrace cesty uživatele se zprostředkovatelem identity:

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

Přečtěte si další informace o cestách uživatelů.

Krok 7: Konfigurace zásad předávající strany

Zásady předávající strany, například SignUpSignIn.xml, určují cestu uživatele, kterou Azure AD B2C spustí. Najděte element DefaultUserJourney v rámci předávající strany. Aktualizujte ID reference tak, aby odpovídalo ID cesty uživatele, do kterého jste přidali zprostředkovatele identity.

V následujícím příkladu Trusona Authentication Cloud je pro cestu uživatele nastavena hodnota ReferenceId 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: Nahrání vlastních zásad

Přihlaste se k portálu Azure.
Pokud máte přístup k více tenantům, v horní nabídce vyberte ikonu Nastavení a v nabídce Adresáře a předplatná přepněte do svého tenanta Azure AD B2C.
Na webu Azure Portal vyhledejte a vyberte Azure AD B2C.
V části Zásady vyberte Architekturu prostředí identit.
Vyberte Nahrát vlastní zásady a potom nahrajte dva soubory zásad, které jste změnili, v následujícím pořadí: zásady rozšíření, například TrustFrameworkExtensions.xml, pak zásady předávající strany, například SignUpOrSignin.xml.

Krok 9: Testování vlastních zásad

V tenantovi Azure AD B2C v části Zásady vyberte Architekturu prostředí identit.
V části Vlastní zásady vyberte TrusonaTacSUSI.
V případě aplikace vyberte webovou aplikaci, kterou jste dříve zaregistrovali jako součást požadavků tohoto článku. například jwt ms. Adresa URL odpovědi by se měla zobrazit https://jwt.ms.
Vyberte Spustit. Váš prohlížeč by měl být přesměrován na přihlašovací stránku Trusona Authentication Cloud.
Zobrazí se přihlašovací obrazovka; v dolní části by mělo být tlačítko pro použití ověřování trusona Authentication Cloud .
Měli byste být přesměrováni do cloudu Trusona Authentication Cloud. Uživateli se zobrazí přihlašovací webová stránka, která požádá o uživatelské jméno – obvykle e-mailovou adresu. Pokud se účet uživatele v cloudu Trusona Authentication Cloud nenajde, odešle se do prohlížeče odpověď, která na zařízení zahájí proces registrace WebAuthn. V opačném případě se do prohlížeče odešle odpověď, která zahájí proces ověřování WebAuthn. Uživateli se zobrazí výzva k výběru přihlašovacích údajů, které se mají použít. Klíč je přidružený k doméně webové aplikace nebo klíče hardwarového zabezpečení. Jakmile uživatel vybere přihlašovací údaje, operační systém požádá uživatele o ověření identity pomocí biometrického kódu, hesla nebo KÓDU PIN. Tím se odemkne zabezpečené prostředí enklávy nebo důvěryhodného spouštění, které generuje ověřovací kontrolní výraz podepsaný privátním klíčem přidruženým k vybraným přihlašovacím údajům.
Pokud je proces přihlášení úspěšný, prohlížeč se přesměruje na https://jwt.msobsah tokenu vráceného službou Azure AD B2C.

Další kroky

Další informace najdete v následujících článcích:

Sdílet prostřednictvím