A Trusona Authentication Cloud konfigurálása az Azure Active Directory B2C-vel

  • Cikk

Ebben a minta oktatóanyagban megtudhatja, hogyan integrálhatja az Azure AD B2C-hitelesítést a Trusona Authentication Cloud használatával. Ez egy felhőalapú szolgáltatás, amely lehetővé teszi a felhasználók számára, hogy érintéses hitelesítéssel hitelesítsék magukat, anélkül, hogy bármilyen mobilhitelesítő alkalmazásra lenne szükségük.

A Trusona Authentication Cloud és az Azure AD B2C integrálásának előnyei a következők:

  • Erős hitelesítést biztosít jobb felhasználói felülettel

    • Boldogabb felhasználók, akik többet költenek online
    • Alacsonyabb mértékű ki- és felhagyás, megnövekedett bevétel
    • Magasabb megőrzés, élettartamérték (LTV)

  • A vállalkozás üzemeltetésének alacsonyabb költsége

    • Csökkentett fiókátvétel és fiókmegosztás
    • Kisebb csalás és kevesebb manuális csaláselemzési művelet
    • Kevesebb kiadás a manuális felülvizsgálatok kiszervezésére

  • Jelszavak kiküszöbölése

    • Nincs több jelszó-visszaállítás
    • Csökkentett telefonos ügyfélszolgálati panaszok
    • Gyors, egyszerű, súrlódásmentes bejelentkezések hozzáférési kulcsokkal

Előfeltételek

A kezdéshez a következők szükségesek:

Forgatókönyv leírása

Web Authentication standard – A WebAuthn modern operációs rendszereket és böngészőket implementál az ujjnyomatos, Windows hello vagy külső FIDO-eszközök, például USB, Bluetooth és OTP segítségével történő hitelesítés támogatásához.

Ebben a forgatókönyvben a Trusona identitásszolgáltatóként (IDP) működik az Azure AD B2C-ben a jelszó nélküli hitelesítés engedélyezéséhez. A megoldást a következő összetevők alkotják:

  • Az Azure AD B2C kombinált bejelentkezési és regisztrációs szabályzatot.
  • A Trusona Authentication Cloud idP-ként van hozzáadva az Azure AD B2C-hez.

Screenshot shows Trusona architecture diagram.

Lépések Leírás
1. A felhasználó a böngészőn keresztül próbál bejelentkezni a webalkalmazásba.
2. A webalkalmazás átirányítja az Azure AD B2C regisztrációs és bejelentkezési szabályzatát.
3. Az Azure AD B2C átirányítja a felhasználót a hitelesítéshez a Trusona Authentication Cloud OpenID Csatlakozás (OIDC) identitásszolgáltatóhoz.
4. A felhasználónak megjelenik egy bejelentkezési weblap, amely a felhasználónevét kéri – általában egy e-mail-címet.
5. A felhasználó megadja az e-mail-címét, és a Folytatás gombra kattint. Ha a felhasználó fiókja nem található a Trusona hitelesítési felhőben, a rendszer választ küld a böngészőnek, amely webauthn regisztrációs folyamatot kezdeményez az eszközön. Ellenkező esetben a rendszer választ küld a WebAuthn hitelesítési folyamatot megkezdő böngészőnek.
6. A rendszer arra kéri a felhasználót, hogy válasszon ki egy használni kívánt hitelesítő adatot. A hozzáférési kulcs a webalkalmazás tartományához vagy egy hardveres biztonsági kulcshoz van társítva. Miután a felhasználó kiválasztott egy hitelesítő adatot, az operációs rendszer megkéri a felhasználót, hogy használjon biometrikus, pin-kód vagy PIN-kód használatával erősítse meg identitását. Ez feloldja a Secure Enclave/Trusted Execution környezetet, amely létrehoz egy hitelesítési állítást, amelyet a kiválasztott hitelesítő adatokhoz társított titkos kulcs ír alá.
7. A hitelesítési állítás visszakerül a Trusona felhőszolgáltatásba ellenőrzés céljából.
8. Az ellenőrzés után a Trusona Authentication Cloud (IdP) létrehoz egy OIDC-azonosító jogkivonatot, majd továbbítja azt az Azure AD B2C-nek (szolgáltató). Az Azure AD B2C ellenőrzi a jogkivonat és a kiállító aláírását a Trusona OpenID felderítési dokumentumában szereplő értékeken. Ezek a részletek az idP beállítása során lettek konfigurálva. Az ellenőrzés után az Azure AD B2C kiad egy OIDC-id_token (a hatókörtől függően), és visszairányítja a felhasználót a jogkivonattal rendelkező kezdeményező alkalmazásba.
9. A webalkalmazás (vagy a hitelesítés implementálásához használt fejlesztői kódtárak) lekéri a jogkivonatot, és ellenőrzi az Azure AD B2C-jogkivonat hitelességét. Ha ez a helyzet, kinyeri a jogcímeket, és átadja azokat a webalkalmazásnak a felhasználáshoz.
10. Ellenőrzéskor a felhasználó hozzáférést kap/megtagad.

1. lépés: Bevezetés a Trusona Authentication Cloud használatával

  1. Jelentkezzen be a Trusona portálra.

  2. A bal oldali navigációs panelen válassza a Gépház

  3. A Gépház menüben válassza ki a csúszkát az OIDC engedélyezéséhez.

  4. Válassza ki a megfelelő bemeneteket, és adja meg az átirányítási URL-címethttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp.

  5. Hozzon létre egy titkos kulcsot, és másolja a kulcsot az Azure AD B2C beállításához.

    Megjegyzés:

    1. A Trusona portál támogatja az önkiszolgáló regisztrációt. A regisztrációkor ön egy csak olvasható jogosultságokkal rendelkező Trusona-fiókhoz lesz hozzárendelve. Ezt követően a Trusona hozzárendeli Önt a megfelelő fiókhoz, és megemeli az olvasási-írási jogosultságokat a szervezet portálfelhasználókra vonatkozó hozzáférés-vezérlési szabályzata alapján.
    2. A Rendszer a Microsoft Entra ID kezdeti tartománynevét használja az ügyfélátirányítási állomásként.

    Screenshot shows Trusona Authentication Cloud portal settings.

2. lépés: Webalkalmazás regisztrálása az Azure AD B2C-ben

Mielőtt az alkalmazások interakcióba lépnének az Azure AD B2C-vel, regisztrálni kell őket az ügyfélbérlében. Ez az oktatóanyag bemutatja, hogyan regisztrálhat webalkalmazásokat az Azure Portalon. Az oktatóanyaghoz hasonló tesztelési célokra regisztrál https://jwt.msegy Microsoft-tulajdonú webalkalmazást, amely megjeleníti egy jogkivonat dekódolt tartalmát (a jogkivonat tartalma soha nem hagyja el a böngészőt). Ha webalkalmazást szeretne regisztrálni az Azure AD B2C-bérlőben, használja az új egységes alkalmazásregisztrációs felületet.

  1. Jelentkezzen be az Azure Portalra.

  2. Ha több bérlőhöz is hozzáfér, a felső menüben válassza a Gépház ikont az Azure AD B2C-bérlőre való váltáshoz a Címtárak + előfizetések menüből.

  3. Az Azure Portalon keresse meg és válassza ki az Azure AD B2C-t.

  4. Válassza a Alkalmazásregisztrációk, majd az Új regisztráció lehetőséget.

  5. Adja meg az alkalmazás nevét. Például jwt ms.

  6. A Támogatott fióktípusok területen válassza a Fiókok lehetőséget bármely identitásszolgáltatóban vagy szervezeti címtárban (a felhasználók felhasználói folyamatokkal való hitelesítéséhez).

  7. Az Átirányítási URI területen válassza a Web lehetőséget, majd írja be https://jwt.ms az URL-cím szövegmezőbe.

    Az átirányítási URI az a végpont, amelyre az engedélyezési kiszolgáló, ebben az esetben az Azure AD B2C küldi a felhasználót. A felhasználóval való interakció befejezése után a rendszer egy hozzáférési jogkivonatot vagy engedélyezési kódot küld a sikeres engedélyezés után. Éles alkalmazásokban ez általában egy nyilvánosan elérhető végpont, ahol az alkalmazás fut, például https://contoso.com/auth-response. Az oktatóanyaghoz hasonló tesztelési célokra beállíthatja azt egy Microsoft-tulajdonú webalkalmazásra https://jwt.ms, amely megjeleníti egy jogkivonat dekódolt tartalmát (a jogkivonat tartalma soha nem hagyja el a böngészőt). Az alkalmazásfejlesztés során hozzáadhatja azt a végpontot, ahol az alkalmazás helyileg figyel, például https://localhost:5000. A regisztrált alkalmazásokban bármikor hozzáadhat és módosíthat átirányítási URI-kat.

    Az átirányítási URI-kra a következő korlátozások vonatkoznak:

    • A válasz URL-címnek a sémával httpskell kezdődnie, kivéve, ha localhost átirányítási URL-címet használ.
    • A válasz URL-címe megkülönbözteti a kis- és nagybetűkre vonatkozó adatokat. Az esetnek meg kell egyeznie a futó alkalmazás URL-elérési útjának esetével. Ha például az alkalmazás az elérési út .../abc/response-oidcrészeként szerepel, ne adja meg .../ABC/response-oidc a válasz URL-címét. Mivel a webböngésző megkülönbözteti a kis- és nagybetűket, a kis- és nagybetűkkel társított .../abc/response-oidc cookie-k kizárhatók, ha a kis- és nagybetűket nem egyező URL-címre irányítják .../ABC/response-oidc át.
    • A válasz URL-címnek tartalmaznia kell vagy ki kell zárnia a záró perjelet, ahogy az alkalmazás elvárja. Előfordulhat például, https://contoso.com/auth-responsehttps://contoso.com/auth-response/ hogy az alkalmazásban nem egyező URL-címekként kezelik őket.

  8. Az Engedélyek csoportban jelölje be a Rendszergazdai hozzájárulás megadása a megnyitáshoz és az engedélyek offline_access jelölőnégyzetet.

  9. Válassza a Regisztrálás lehetőséget.

Az azonosító jogkivonat implicit engedélyezése

Ha regisztrálja ezt az alkalmazást, és az alkalmazással https://jwt.ms/ konfigurálja egy felhasználói folyamat vagy egyéni szabályzat teszteléséhez, engedélyeznie kell az implicit engedélyezési folyamatot az alkalmazásregisztrációban:

  1. A bal oldali menü Kezelés területén válassza a Hitelesítés lehetőséget.

  2. Az Implicit engedélyezési és hibrid folyamatok területen jelölje be az azonosító jogkivonatok (implicit és hibrid folyamatokhoz használt) jelölőnégyzeteit.

  3. Válassza a Mentés parancsot.

3. lépés: A Trusona Authentication Cloud konfigurálása identitásszolgáltatóként az Azure AD B2C-ben

  1. Jelentkezzen be az Azure Portalra az Azure AD B2C-bérlő globális rendszergazdájaként.

  2. Ha több bérlőhöz is hozzáfér, a felső menüben válassza a Gépház ikont az Azure AD B2C-bérlőre való váltáshoz a Címtárak + előfizetések menüből.

  3. Válassza az Azure Portal bal felső sarkában található Minden szolgáltatás lehetőséget, majd keresse meg és válassza ki az Azure AD B2C-t.

  4. Lépjen az Irányítópult>Azure Active Directory B2C-identitásszolgáltatókhoz.>

  5. Válassza ki az identitásszolgáltatókat.

  6. Select Add.

IdP konfigurálása

  1. Válassza az Identitásszolgáltató típusa OpenID Csatlakozás (előzetes verzió) lehetőséget>.

  2. Töltse ki az űrlapot az azonosító beállításához:

    Tulajdonság Érték
    Metaadatok URL-címe https://authcloud.trusona.net/.well-known/openid-configuration
    Ügyfél azonosítója elérhető a Trusona Authentication Cloud portálon
    Titkos ügyfélkód elérhető a Trusona Authentication Cloud portálon
    Scope OpenID-profil e-mail-címe
    Válasz típusa code
    Válasz mód form_post

  3. Válassza az OK lehetőséget.

  4. Válassza az identitásszolgáltató jogcímeinek megfeleltetése lehetőséget.

  5. Töltse ki az űrlapot az identitásszolgáltató leképezéséhez:

    Tulajdonság Érték
    UserID Al
    Megjelenítendő név Felhasználónév
    Utónév given_name
    Surname family_name
    Válasz mód e-mail

  6. Kattintson az OK gombra az új OIDC-azonosító beállításának befejezéséhez.

4. lépés: Felhasználói folyamat szabályzatának létrehozása

A Trusona mostantól új OpenID-Csatlakozás identitásszolgáltatóként jelenik meg a B2C-azonosítókban.

  1. Az Azure AD B2C-bérlő Szabályzatok területén válassza ki a Felhasználói folyamatok lehetőséget.

  2. Select New user flow.

  3. Válassza a Regisztráció és bejelentkezés lehetőséget, válasszon ki egy verziót, majd válassza a Létrehozás lehetőséget.

  4. Adja meg a szabályzat nevét.

  5. Az Identitásszolgáltatók szakaszban válassza ki az újonnan létrehozott Trusona Authentication Cloud-Identity Providert.

    Megjegyzés:

    Mivel a Trusona eredendően többtényezős, a legjobb, ha letiltja a többtényezős hitelesítést.

  6. Select Create.

  7. A Felhasználói attribútumok és jogcímek csoportban válassza a Továbbiak megjelenítése lehetőséget. Az űrlapon válasszon ki legalább egy attribútumot, amelyet az identitásszolgáltató korábbi szakaszában megadott.

  8. Válassza az OK lehetőséget.

5. lépés: A felhasználói folyamat tesztelése

  1. Válassza ki a létrehozott szabályzatot.

  2. Válassza a Felhasználói folyamat futtatása lehetőséget, majd válassza ki a beállításokat:

    a. Alkalmazás: Válassza ki a regisztrált alkalmazást, például jwt ms.

    b. Válasz URL-címe: Válassza ki például https://jwt.msaz átirányítási URL-címet.

  3. Válassza a Felhasználói folyamat futtatása lehetőséget. A rendszer átirányítja a Trusona hitelesítési felhőbe. A felhasználónak megjelenik egy bejelentkezési weblap, amely a felhasználónevét kéri – általában egy e-mail-címet. Ha a felhasználó fiókja nem található a Trusona Authentication Cloudban, a rendszer választ küld a böngészőnek, amely webauthn regisztrációs folyamatot kezdeményez az eszközön. Ellenkező esetben a rendszer választ küld a WebAuthn hitelesítési folyamatot megkezdő böngészőnek. A rendszer arra kéri a felhasználót, hogy válasszon ki egy használni kívánt hitelesítő adatot. A hozzáférési kulcs a webalkalmazás tartományához vagy egy hardveres biztonsági kulcshoz van társítva. Miután a felhasználó kiválasztott egy hitelesítő adatot, az operációs rendszer megkéri a felhasználót, hogy használjon biometrikus, pin-kód vagy PIN-kód használatával erősítse meg identitását. Ez feloldja a Secure Enclave/Trusted Execution környezetet, amely létrehoz egy hitelesítési állítást, amelyet a kiválasztott hitelesítő adatokhoz társított titkos kulcs ír alá. Az Azure AD B2C ellenőrzi a Trusona hitelesítési választ, és kiad egy OIDC-jogkivonatot. Visszairányítja a felhasználót például a kezdeményező alkalmazásba, https://jwt.msamely megjeleníti az Azure AD B2C által visszaadott jogkivonat tartalmát.

3. lépés: Trusona authentication cloud policy key létrehozása

Tárolja a korábban az 1. lépésben létrehozott ügyféltitkot az Azure AD B2C-bérlőben.

  1. Jelentkezzen be az Azure Portalra.

  2. Ha több bérlőhöz is hozzáfér, a felső menüben válassza a Gépház ikont az Azure AD B2C-bérlőre való váltáshoz a Címtárak + előfizetések menüből.

  3. Válassza az Összes szolgáltatást az Azure Portal bal felső sarkában, majd keresse meg és válassza az Azure AD B2C-t.

  4. Az Áttekintés lapon válassza az Identity Experience Framework lehetőséget.

  5. Válassza a Házirendkulcsok lehetőséget, majd válassza a Hozzáadás lehetőséget.

  6. A Beállítások beállításnál válassza a Manuális lehetőséget.

  7. Adja meg a szabályzatkulcs nevét. For example, TrusonaTacClientSecret. A rendszer automatikusan hozzáadja az előtagot B2C_1A_ a kulcs nevéhez.

  8. A Titkos kód mezőbe írja be a korábban rögzített ügyfélkulcsot.

  9. Kulcshasználat esetén válassza a Signaturelehetőséget.

  10. Select Create.

4. lépés: A Trusona Authentication Cloud konfigurálása idP-ként

Tipp.

Ezen a ponton konfigurálnia kell az Azure AD B2C-szabályzatot. Ha nem, kövesse az Azure AD B2C-bérlő beállítására és a szabályzatok konfigurálására vonatkozó utasításokat .

Ahhoz, hogy a felhasználók a Trusona Authentication Cloud használatával jelentkezzenek be, meg kell határoznia a Trusonát jogcímszolgáltatóként, amellyel az Azure AD B2C egy végponton keresztül tud kommunikálni. A végpont olyan jogcímeket biztosít, amelyeket az Azure AD B2C használ annak ellenőrzésére, hogy egy adott felhasználó az eszközén elérhető jelszóval vagy hardveres biztonsági kulccsal hitelesítette-e a felhasználó identitását.

A Trusona jogcímszolgáltatóként való hozzáadásához kövesse az alábbi lépéseket:

  1. Kérje le az egyéni szabályzat kezdőcsomagjait a GitHubról, majd frissítse a LocalAccounts kezdőcsomag XML-fájljait az Azure AD B2C-bérlő nevével:

    1. Töltse le a .zip fájlt , vagy klónozza az adattárat:

          git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack

    2. A LocalAccounts könyvtárban lévő összes fájlban cserélje le a sztringet yourtenant az Azure AD B2C-bérlő nevére. Ha például a B2C-bérlő neve az contoso, akkor az összes példány yourtenant.onmicrosoft.com lesz contoso.onmicrosoft.com.

  2. Nyissa meg a következőt: LocalAccounts/TrustFrameworkExtensions.xml.

  3. Keresse meg a ClaimsProviders elemet. Ha nem létezik, adja hozzá a gyökérelem alá. TrustFrameworkPolicy

  4. Adjon hozzá egy új ClaimsProvidert az alábbihoz hasonló módon:

<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. Állítsa client_id az 1. lépésben korábban rögzített Trusona Authentication Cloud-alkalmazásazonosítóval.

  2. Frissítse client_secret szakaszt a 3. lépésben létrehozott szabályzatkulcs nevével. Például B2C_1A_TrusonaTacClientSecret:

    <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />

  3. Save the changes.

5. lépés: Felhasználói folyamat hozzáadása

Ezen a ponton beállította az identitásszolgáltatót, de még nem érhető el egyik bejelentkezési lapon sem. Ha a saját egyéni felhasználói folyamata továbbhalad a 6. lépésre, ellenkező esetben hozzon létre egy meglévő sablonfelhasználói folyamat másolatát az alábbiak szerint:

  1. Nyissa meg a LocalAccounts/TrustFrameworkBase.xml fájlt a kezdőcsomagból.

  2. Keresse meg és másolja ki a UserJourney elem teljes tartalmát, amely tartalmazza Id=SignUpOrSignIna elemet.

  3. Nyissa meg a LocalAccounts/TrustFrameworkExtensions.xml UserJourneys elemet, és keresse meg. Ha az elem nem létezik, adjon hozzá egyet.

  4. Illessze be a UserJourney elem gyermekként másolt UserJourney elem teljes tartalmát.

  5. Nevezze át a Id felhasználói folyamatot. For example, Id=TrusonaTacSUSI.

6. lépés: Az identitásszolgáltató hozzáadása egy felhasználói folyamathoz

Most, hogy már rendelkezik felhasználói folyamatokkal, adja hozzá az új azonosítót a felhasználói folyamathoz.

  1. Keresse meg a vezénylési lépés azon elemét, amely tartalmazza Type=CombinedSignInAndSignUpvagy Type=ClaimsProviderSelection a felhasználói folyamat során. Általában ez az első vezénylési lépés. A ClaimsProviderSelections elem azon azonosítók listáját tartalmazza, amelyekkel a felhasználó bejelentkezhet. Az elemek sorrendje szabályozza a felhasználónak megjelenített bejelentkezési gombok sorrendjét. Adjon hozzá egy ClaimsProviderSelection XML-elemet. Állítsa be a TargetClaimsExchangeId értékét egy felhasználóbarát névre, példáulTrusonaTacExchange.

  2. A következő vezénylési lépésben adjon hozzá egy ClaimsExchange elemet. Állítsa az azonosítót a cél jogcímcsere-azonosító értékére. Frissítse a TechnicalProfileReferenceId értékét a korábban létrehozott műszaki profil azonosítójára, miközben hozzáadja például TrusonaTAC-OpenIdConnecta jogcímszolgáltatót.

Az alábbi XML bemutatja a felhasználói folyamatnak az identitásszolgáltatóval való vezénylési lépéseit:

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

További információ a felhasználói utazásokról.

7. lépés: A függő entitás házirendjének konfigurálása

A függő entitás szabályzata( például SignUpSignIn.xml) meghatározza az Azure AD B2C által végrehajtott felhasználói folyamatot. Keresse meg a DefaultUserJourney elemet a függő entitáson belül. Frissítse a referenciaazonosítót a felhasználói útazonosítónak megfelelően, amelyben hozzáadta az identitásszolgáltatót.

A következő példában a Trusona Authentication Cloud felhasználói folyamat referenciaazonosítója a következőre TrusonaTacSUSIvan állítva:

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

8. lépés: Az egyéni szabályzat feltöltése

  1. Jelentkezzen be az Azure Portalra.

  2. Ha több bérlőhöz is hozzáfér, a felső menüben válassza a Gépház ikont az Azure AD B2C-bérlőre való váltáshoz a Címtárak + előfizetések menüből.

  3. Az Azure Portalon keresse meg és válassza ki az Azure AD B2C-t.

  4. A Szabályzatok területen válassza az Identity Experience Framework lehetőséget.

  5. Válassza az Egyéni házirend feltöltése lehetőséget, majd töltse fel a módosított két házirendfájlt a következő sorrendben: a bővítményházirend, például TrustFrameworkExtensions.xmla függő entitás házirendje, például SignUpOrSignin.xml.

9. lépés: Az egyéni szabályzat tesztelése

  1. Az Azure AD B2C-bérlő Szabályzatok területén válassza az Identity Experience Framework lehetőséget.

  2. Az Egyéni szabályzatok területen válassza a TrusonaTacSUSI lehetőséget.

  3. Alkalmazás esetén válassza ki azt a webalkalmazást, amelyet korábban a jelen cikk előfeltételeinek részeként regisztrált. például jwt ms. A Válasz URL-címnek meg kell jelennie https://jwt.ms.

  4. Válassza a Futtatás most lehetőséget. A böngészőt át kell irányítani a Trusona Authentication Cloud bejelentkezési oldalára.

  5. Megjelenik egy bejelentkezési képernyő; alul egy gombnak kell lennie a Trusona Authentication Cloud-hitelesítés használatához.

  6. A rendszer átirányítja a Trusona Authentication Cloud szolgáltatásba. A felhasználónak megjelenik egy bejelentkezési weblap, amely a felhasználónevét kéri – általában egy e-mail-címet. Ha a felhasználó fiókja nem található a Trusona hitelesítési felhőben, a rendszer választ küld a böngészőnek, amely webauthn regisztrációs folyamatot kezdeményez az eszközön. Ellenkező esetben a rendszer választ küld a WebAuthn hitelesítési folyamatot megkezdő böngészőnek. A rendszer arra kéri a felhasználót, hogy válasszon ki egy használni kívánt hitelesítő adatot. A hozzáférési kulcs a webalkalmazás tartományához vagy egy hardveres biztonsági kulcshoz van társítva. Miután a felhasználó kiválasztott egy hitelesítő adatot, az operációs rendszer megkéri a felhasználót, hogy használjon biometrikus, pin-kód vagy PIN-kód használatával erősítse meg identitását. Ez feloldja a Secure Enclave/Trusted Execution környezetet, amely létrehoz egy hitelesítési állítást, amelyet a kiválasztott hitelesítő adatokhoz társított titkos kulcs ír alá.

  7. Ha a bejelentkezési folyamat sikeres, a rendszer átirányítja a böngészőt, amely megjeleníti az Azure AD B2C által visszaadott https://jwt.msjogkivonat tartalmát.

Következő lépések

További információkért tekintse át a következő cikkeket: