Konfigurace Asignio s Azure Active Directory B2C pro vícefaktorové ověřování

Zjistěte, jak integrovat ověřování Microsoft Entra ID (Azure AD B2C) s Asignio. Díky této integraci poskytuje zákazníkům prostředí bez hesla, měkké biometrické a vícefaktorové ověřování. Asignio používá k ověřování uživatelů patentovaný podpis Asignio a živé ověření obličeje. Měnitelný biometrický podpis pomáhá omezit opakované používání hesel, podvodů, útoků phishing a přihlašovacích údajů prostřednictvím vícekanálového ověřování.

Než začnete

Zvolte selektor typu zásady, který označuje nastavení typu zásady. Azure AD B2C má dvě metody, jak definovat způsob interakce uživatelů s vašimi aplikacemi:

• Předdefinované toky uživatelů
• Konfigurovatelné vlastní zásady

Postup v tomto článku se pro každou metodu liší.

Další informace:

• Přehled toků uživatelů a vlastních zásad
• přehled vlastních zásad Azure AD B2C

Požadavky

• Předplatné Azure.

• Pokud nemáte zapnutý, získejte bezplatný účet Azure.

• Tenant Azure AD B2C propojený s předplatným Azure

• Viz Kurz: Vytvoření tenanta Azure Active Directory B2C.

• ID klienta Asignio a tajný klíč klienta vystavený společností Asignio.

• Tyto tokeny se získávají registrací mobilních nebo webových aplikací v Asignio.

Pro vlastní zásady

Dokončení kurzu: Vytváření toků uživatelů a vlastních zásad v Azure AD B2C

Popis scénáře

Tato integrace zahrnuje následující komponenty:

• Azure AD B2C – autorizační server, který ověřuje přihlašovací údaje uživatele
• Webové nebo mobilní aplikace – zabezpečení pomocí Asignio MFA
• Webová aplikace Asignio – biometrické shromažďování podpisů na dotykovém zařízení uživatele

Následující diagram znázorňuje implementaci.

1. Uživatel otevře Azure AD přihlašovací stránku B2C ve své mobilní nebo webové aplikaci a pak se přihlásí nebo zaregistruje.
2. Azure AD B2C přesměruje uživatele do Asignio pomocí požadavku OpenID Connect (OIDC).
3. Uživatel je přesměrován do webové aplikace Asignio pro biometrické přihlášení. Pokud uživatel nezaregistroval svůj podpis Asignio, může k ověření použít jednorázové heslo SMS. Po ověření uživatel obdrží registrační odkaz pro vytvoření podpisu Asignio.
4. Uživatel se ověřuje pomocí podpisu Asignio a ověření obličeje nebo pomocí ověření hlasu a obličeje.
5. Odpověď na výzvu dostane Asignio.
6. Asignio vrátí odpověď OIDC na přihlášení Azure AD B2C.
7. Azure AD B2C odešle Asignio žádost o ověření, aby potvrdil přijetí ověřovacích dat.
8. Uživateli je udělen nebo odepřen přístup k aplikaci.

Konfigurace aplikace pomocí Asignio

Ke konfiguraci aplikace pomocí Asignio se používá web pro správu partnerů Asignio.

1. Přejděte na stránku asignio.com Asignio Partner Administration a požádejte o přístup pro vaši organizaci.
2. Pomocí přihlašovacích údajů se přihlaste ke správě partnerů Asignio.
3. Vytvořte záznam pro aplikaci Azure AD B2C pomocí tenanta Azure AD B2C. Pokud používáte Azure AD B2C se službou Asignio, Azure AD B2C spravuje připojené aplikace. Aplikace Asignio představují aplikace v Azure Portal.
4. V lokalitě pro správu partnera Asignio vygenerujte ID klienta a tajný klíč klienta.
5. Poznamenejte si a uložte ID klienta a tajný klíč klienta. Použijete je později. Asignio neukládá tajné kódy klienta.
6. Zadejte identifikátor URI přesměrování na webu, ke které se uživatel vrátí po ověření. Použijte následující vzor identifikátoru URI.

[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp].

7. Nahrajte logo společnosti. Zobrazí se při ověřování Asignio, když se uživatelé přihlásí.

Registrace webové aplikace v Azure AD B2C

Zaregistrujte aplikace v tenantovi, který spravujete, a pak můžou komunikovat s Azure AD B2C.

Další informace: Typy aplikací, které je možné použít v Active Directory B2C

Pro účely tohoto kurzu registrujete https://jwt.mswebovou aplikaci Microsoftu s dekódovaným obsahem tokenů, který neopustí váš prohlížeč.

Registrace webové aplikace a povolení implicitního udělení tokenu ID

Dokončení kurzu: Registrace webové aplikace v Azure Active Directory B2C

Konfigurace Asignio jako zprostředkovatele identity v Azure AD B2C

Následující pokyny najdete v Microsoft Entra tenanta s předplatným Azure.

1. Přihlaste se k Azure Portal jako globální správce tenanta Azure AD B2C.
2. Na panelu nástrojů Azure Portal vyberte Adresáře a předplatná.
3. V nastavení portálu | Adresáře a předplatná v seznamu Název adresáře vyhledejte adresář Microsoft Entra.
4. Vyberte Přepnout.
5. V levém horním rohu Azure Portal vyberte Všechny služby.
6. Vyhledejte a vyberte Azure AD B2C.
7. V Azure Portal vyhledejte a vyberte Azure AD B2C.
8. V nabídce vlevo vyberte Zprostředkovatelé identity.
9. Vyberte New OpenID Connect Provider (Nový zprostředkovatel OpenID Connect).
10. Vyberte Typ >zprostředkovatele identityOpenID Connect.
11. Do pole Název zadejte přihlašovací jméno Asignio nebo název, který zvolíte.
12. Jako Adresu URL metadat zadejte https://authorization.asignio.com/.well-known/openid-configuration.
13. Jako ID klienta zadejte ID klienta, které jste vygenerovali.
14. Do pole Tajný klíč klienta zadejte vygenerovaný tajný klíč klienta.
15. Jako Rozsah použijte e-mailový profil openid.
16. Jako Typ odpovědi použijte kód.
17. Pro režim odpovědi použijte dotaz.
18. Jako nápovědu k doméně použijte https://asignio.com.
19. Vyberte OK.
20. Vyberte Mapovat deklarace identity tohoto zprostředkovatele identity.
21. Jako ID uživatele použijte sub.
22. Jako Zobrazovaný název použijte název.
23. Jako Křestní jméno použijte given_name.
24. V části Příjmení použijte family_name.
25. Pro Email použijte e-mail.
26. Vyberte Uložit.

SVytvoření zásad toku uživatele

1. V tenantovi Azure AD B2C v části Zásady vyberte Toky uživatelů.
2. Vyberte Nový tok uživatele.
3. Vyberte Typ toku uživatele Zaregistrovat se a přihlásit se.
4. Vyberte Doporučená verze.
5. Vyberte Vytvořit.
6. Zadejte název toku uživatele, například AsignioSignupSignin.
7. V části Zprostředkovatelé identity u místních účtů vyberte Žádné. Tato akce zakáže ověřování e-mailů a hesel.
8. V části Vlastní zprostředkovatelé identity vyberte vytvořeného zprostředkovatele identity Asignio.
9. Vyberte Vytvořit.

Testování toku uživatele

1. V tenantovi Azure AD B2C vyberte Toky uživatelů.
2. Vyberte vytvořený tok uživatele.
3. V části Aplikace vyberte webovou aplikaci, kterou jste zaregistrovali. Adresa URL odpovědi je https://jwt.ms.
4. Vyberte Spustit tok uživatele.
5. Prohlížeč se přesměruje na přihlašovací stránku Asignio.
6. Zobrazí se přihlašovací obrazovka.
7. V dolní části vyberte Ověřování Asignio .

Pokud máte podpis Asignio, dokončete výzvu k ověření. Pokud ne, zadejte telefonní číslo zařízení pro ověření prostřednictvím SMS jednorázového hesla. Pomocí odkazu zaregistrujte svůj podpis Asignio.

8. Prohlížeč se přesměruje na https://jwt.ms. Zobrazí se obsah tokenu vrácený Azure AD B2C.

Vytvoření klíče zásad Asignio

1. Vygenerovaný tajný klíč klienta uložte v tenantovi Azure AD B2C.
2. Přihlaste se k webu Azure Portal.
3. Na panelu nástrojů portálu vyberte Adresáře a předplatná.
4. V nastavení portálu | Adresáře a předplatná najděte v seznamu Název adresáře svůj adresář Azure AD B2C.
5. Vyberte Přepnout.
6. V levém horním rohu Azure Portal vyberte Všechny služby.
7. Vyhledejte a vyberte Azure AD B2C.
8. Na stránce Přehled vyberte Architektura prostředí identit.
9. Vyberte Klíče zásad.
10. Vyberte Přidat.
11. V části Možnosti vyberte Ručně.
12. Zadejte klíč zásady Název klíče zásad. Předpona B2C_1A_ se připojí k názvu klíče.
13. Do pole Tajné zadejte tajný kód klienta, který jste si poznamenali.
14. V části Použití klíče vyberte Podpis.
15. Vyberte Vytvořit.

Konfigurace Asignio jako zprostředkovatele identity

Tip

Než začnete, ujistěte se, že jsou nakonfigurované zásady Azure AD B2C. Pokud ne, postupujte podle pokynů v úvodním balíčku vlastních zásad.

Aby se uživatelé mohli přihlásit pomocí Asignio, definujte Asignio jako zprostředkovatele deklarací identity, se kterým Azure AD B2C komunikuje prostřednictvím koncového bodu. Koncový bod poskytuje deklarace identity, Azure AD B2C používá k ověření ověřování uživatelů pomocí digitálního ID na zařízení.

Přidání Asignio jako zprostředkovatele deklarací identity

Získejte úvodní balíčky vlastních zásad z GitHubu a pak aktualizujte soubory XML v úvodní sadě LocalAccounts názvem vašeho tenanta Azure AD B2C:

1. Stáhněte soubor zip active-directory-b2c-custom-policy-starterpack nebo naklonujte úložiště:

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

2. V souborech v adresáři LocalAccounts nahraďte řetězec yourtenant Azure AD název tenanta B2C.

3. Otevřete LocalAccounts/ TrustFrameworkExtensions.xml.

4. Vyhledejte element ClaimsProviders . Pokud žádný neexistuje, přidejte ho do kořenového elementu TrustFrameworkPolicy.

5. Přidejte nový ClaimsProvider podobný následujícímu příkladu:

    <ClaimsProvider>
      <Domain>contoso.com</Domain>
      <DisplayName>Asignio</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Asignio-Oauth2">
          <DisplayName>Asignio</DisplayName>
          <Description>Login with your Asignio account</Description>
          <Protocol Name="OAuth2" />
          <Metadata>
            <Item Key="ProviderName">authorization.asignio.com</Item>
            <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>
            <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>
            <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>
            <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>
            <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="scope">openid profile email</Item>
            <Item Key="UsePolicyInRedirectUri">0</Item>
            <!-- Update the Client ID below to the Asignio Application ID -->
            <Item Key="client_id">00000000-0000-0000-0000-000000000000</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="22222222-2222-2222-2222-222222222222"></Item>
            <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
            <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
            <!-- The commented key below 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>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
          </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://authorization.asignio.com" />
            <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
   

6. Nastavte client_id pomocí ID aplikace Asignio, které jste si poznamenali.

7. Aktualizujte client_secret oddílu klíčem zásad, který jste vytvořili. Příklad B2C_1A_AsignioSecret:

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

8. Uložte změny.

Přidání cesty uživatele

Zprostředkovatel identity není na přihlašovacích stránkách.

1. Pokud máte vlastní cestu uživatele, pokračujte konfigurací zásad předávající strany, jinak zkopírujte cestu uživatele šablony:
2. V úvodním balíčku otevřete LocalAccounts/ TrustFrameworkBase.xml.
3. Vyhledejte a zkopírujte obsah elementu UserJourney , který obsahuje Id=SignUpOrSignIn.
4. Otevřete LocalAccounts/ TrustFrameworkExtensions.xml.
5. Vyhledejte element UserJourneys . Pokud žádný není, přidejte ho.
6. Vložte obsah elementu UserJourney jako podřízený element UserJourneys.]
7. Přejmenujte ID cesty uživatele. Například, Id=AsignioSUSI.

Další informace: Cesty uživatelů

Přidání zprostředkovatele identity k cestě uživatele

Přidejte nového zprostředkovatele identity do cesty uživatele.

1. Vyhledejte element kroku orchestrace, který zahrnuje Type=CombinedSignInAndSignUp, nebo Type=ClaimsProviderSelection v cestě uživatele. Obvykle se jedná o první krok orchestrace. Element ClaimsProviderSelections obsahuje seznam zprostředkovatelů identity, pomocí kterého se uživatelé přihlašují. Pořadí prvků řídí pořadí tlačítek pro přihlášení.
2. Přidejte element XML ClaimsProviderSelection .
3. Nastavte hodnotu TargetClaimsExchangeId na popisný název.
4. Přidejte element ClaimsExchange .
5. Nastavte ID na hodnotu ID cílové výměny deklarací identity.
6. Aktualizujte hodnotu TechnicalProfileReferenceId na ID vytvořeného technického profilu.

Následující kód XML ukazuje orchestraci cest uživatelů se zprostředkovatelem identity.

    <UserJourney Id="AsignioSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />
            <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="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />
            <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 (i.e. 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>

Konfigurace zásad předávající strany

Zásady předávající strany, například SignUpSignIn.xml, určují cestu uživatele, Azure AD B2C provede.

1. V předávající straně vyhledejte element DefaultUserJourney .
2. Aktualizujte ReferenceId tak, aby odpovídalo ID cesty uživatele, do kterého jste přidali zprostředkovatele identity.

V následujícím příkladu AsignioSUSI je pro cestu uživatele hodnota ReferenceId nastavená na AsignioSUSIhodnotu :

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

Nahrání vlastní zásady

1. Přihlaste se k webu Azure Portal.
2. Na panelu nástrojů portálu vyberte Adresáře a předplatná.
3. V nastavení portálu | Adresáře a předplatná najděte v seznamu Název adresáře svůj adresář Azure AD B2C.
4. Vyberte Přepnout.
5. V Azure Portal vyhledejte a vyberte Azure AD B2C.
6. V části Zásady vyberte Architektura prostředí identit.
7. Vyberte Nahrát vlastní zásady.
8. Nahrajte dva soubory zásad, které jste změnili, v následujícím pořadí:

• Zásady rozšíření, například TrustFrameworkExtensions.xml
• Zásady předávající strany, například SignUpOrSignin.xml

Testování vlastních zásad

1. V tenantovi Azure AD B2C a v části Zásady vyberte Architektura prostředí identit.
2. V části Vlastní zásady vyberte AsignioSUSI.
3. V části Aplikace vyberte webovou aplikaci, kterou jste zaregistrovali. Adresa URL odpovědi je https://jwt.ms.
4. Vyberte Spustit.
5. Prohlížeč se přesměruje na přihlašovací stránku Asignio.
6. Zobrazí se přihlašovací obrazovka.
7. V dolní části vyberte Ověřování Asignio .

Pokud máte podpis Asignio, zobrazí se výzva k ověření pomocí podpisu Asignio. Pokud ne, zadejte telefonní číslo zařízení, které se má ověřit pomocí jednorázového hesla SMS. Pomocí odkazu zaregistrujte svůj podpis Asignio.

8. Prohlížeč se přesměruje na https://jwt.ms. Zobrazí se obsah tokenu vrácený Azure AD B2C.

Další kroky

• Řešení a školení pro Azure Active Directory B2C
• Ptejte se na Stackoverflow
• ukázky Azure AD B2C
• YouTube: Řada Identit Azure AD B2C
• přehled vlastních zásad Azure AD B2C
• Kurz: Vytváření toků uživatelů a vlastních zásad v Azure Active Directory B2C