Nastavení toku registrace a přihlášení pomocí účtu sociálních sítí pomocí vlastních zásad Azure Active Directory B2C
V části Nastavení toku registrace a přihlašování pomocí článku o vlastních zásadách Azure Active Directory B2C nastavíme tok registrace pro místní účet pomocí Azure Active Directory B2C (Azure AD B2C).
V tomto článku přidáme tok přihlašování pro externí účet, například účet sociální sítě, jako je Facebook. V tomto případě Azure AD B2C umožňuje uživateli přihlásit se k vaší aplikaci pomocí přihlašovacích údajů z externího zprostředkovatele sociální identity (IdP).
U místních účtů je uživatelský účet jednoznačně identifikován pomocí atributu objectIduživatele. Pro externí zprostředkovatele identity používáme alternativeSecurityId atribut uživatele, i když objectId stále existuje.
Předpoklady
Pokud ho ještě nemáte, vytvořte tenanta Azure AD B2C, který je propojený s vaším předplatným Azure.
Zaregistrujte webovou aplikaci a povolte implicitní udělení tokenu ID. Pro identifikátor URI přesměrování použijte https://jwt.ms.
V počítači musíte mít nainstalovaný Visual Studio Code (VS Code ).
Pomocí vlastních zásad Azure Active Directory B2C dokončete postup nastavení toku registrace a přihlašování pro místní účet. Tento článek je součástí vytváření a spouštění vlastních zásad, které vás provedou řadou návodů.
Poznámka:
Tento článek je součástí řady s návody k vytvoření a spuštění vlastních zásad v Azure Active Directory B2C. Doporučujeme spustit tuto řadu z prvního článku.
Krok 1 : Vytvoření facebookové aplikace
Pomocí kroků uvedených v části Vytvoření facebookové aplikace získejte ID aplikace Pro Facebook a tajný kód aplikace. Přeskočte požadavky a zbývající kroky v části Nastavení registrace a přihlaste se pomocí článku o facebookovém účtu .
Krok 2 – Vytvoření klíče zásad pro Facebook
Použijte kroky popsané v tématu Vytvoření klíče Facebooku a uložte klíč zásad ve vašem tenantovi Azure AD B2C. Přeskočte požadavky a zbývající kroky v části Nastavení registrace a přihlaste se pomocí článku o facebookovém účtu .
Krok 3 : Konfigurace přihlášení pomocí Facebooku
Pokud chcete nakonfigurovat přihlášení pomocí Facebooku, musíte provést následující kroky:
- Deklarace dalších deklarací identity
- Definujte další transformace deklarací identity, které vám pomůžou s manipulacemi s deklaracemi, jako je například vytváření
AlternativeSecurityId. - Konfigurace zprostředkovatele deklarací identity facebooku
- Nakonfigurujte technické profily Microsoft Entra pro čtení a zápis účtu ze sociální sítě a do databáze Microsoft Entra.
- Nakonfigurujte technický profil s vlastním kontrolním výrazem (pro přijetí dalšího vstupu od uživatele nebo aktualizaci podrobností o uživateli) a jeho definici obsahu.
Krok 3.1 – Deklarace dalších deklarací identity
ContosoCustomPolicy.XML V souboru vyhledejte ClaimsSchema oddíl a deklarujte další deklarace identity pomocí následujícího kódu:
<!--<ClaimsSchema>-->
...
<ClaimType Id="issuerUserId">
<DisplayName>Username</DisplayName>
<DataType>string</DataType>
<UserHelpText/>
<UserInputType>TextBox</UserInputType>
<Restriction>
<Pattern RegularExpression="^[a-zA-Z0-9]+[a-zA-Z0-9_-]*$" HelpText="The username you provided is not valid. It must begin with an alphabet or number and can contain alphabets, numbers and the following symbols: _ -" />
</Restriction>
</ClaimType>
<ClaimType Id="identityProvider">
<DisplayName>Identity Provider</DisplayName>
<DataType>string</DataType>
<UserHelpText/>
</ClaimType>
<ClaimType Id="authenticationSource">
<DisplayName>AuthenticationSource</DisplayName>
<DataType>string</DataType>
<UserHelpText>Specifies whether the user was authenticated at Social IDP or local account.</UserHelpText>
</ClaimType>
<ClaimType Id="upnUserName">
<DisplayName>UPN User Name</DisplayName>
<DataType>string</DataType>
<UserHelpText>The user name for creating user principal name.</UserHelpText>
</ClaimType>
<ClaimType Id="alternativeSecurityId">
<DisplayName>AlternativeSecurityId</DisplayName>
<DataType>string</DataType>
<UserHelpText/>
</ClaimType>
<ClaimType Id="mailNickName">
<DisplayName>MailNickName</DisplayName>
<DataType>string</DataType>
<UserHelpText>Your mail nick name as stored in the Azure Active Directory.</UserHelpText>
</ClaimType>
<ClaimType Id="newUser">
<DisplayName>User is new or not</DisplayName>
<DataType>boolean</DataType>
<UserHelpText/>
</ClaimType>
<!--</ClaimsSchema>-->
Krok 3.2 – Definování transformací deklarací identity
ContosoCustomPolicy.XML V souboru vyhledejte ClaimsTransformations prvek a přidejte transformace deklarací identity pomocí následujícího kódu:
<!--<ClaimsTransformations>-->
...
<ClaimsTransformation Id="CreateRandomUPNUserName" TransformationMethod="CreateRandomString">
<InputParameters>
<InputParameter Id="randomGeneratorType" DataType="string" Value="GUID" />
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
<ClaimsTransformation Id="CreateAlternativeSecurityId" TransformationMethod="CreateAlternativeSecurityId">
<InputClaims>
<InputClaim ClaimTypeReferenceId="issuerUserId" TransformationClaimType="key" />
<InputClaim ClaimTypeReferenceId="identityProvider" TransformationClaimType="identityProvider" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="alternativeSecurityId" TransformationClaimType="alternativeSecurityId" />
</OutputClaims>
</ClaimsTransformation>
<ClaimsTransformation Id="CreateUserPrincipalName" TransformationMethod="FormatStringClaim">
<InputClaims>
<InputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="inputClaim" />
</InputClaims>
<InputParameters>
<InputParameter Id="stringFormat" DataType="string" Value="cpim_{0}@{RelyingPartyTenantId}" />
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="userPrincipalName" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
<!--</ClaimsTransformations>-->
Definovali jsme tři transformace deklarací identity, které používáme k vygenerování hodnot a alternativeSecurityIduserPrincipalName deklarací identity. Tyto deklarace IdentityTransformations jsou vyvolány v technickém profilu OAuth2 v kroku 3.3.
Krok 3.3 – Konfigurace zprostředkovatele deklarací identity na Facebooku
Pokud chcete uživatelům umožnit přihlášení pomocí facebookového účtu, musíte ho definovat jako zprostředkovatele deklarací identity, se kterým může Azure AD B2C komunikovat prostřednictvím koncového bodu. Facebookový účet můžete definovat jako zprostředkovatele deklarací identity.
ContosoCustomPolicy.XML V souboru vyhledejte ClaimsProviders prvek, přidejte nového zprostředkovatele deklarací pomocí následujícího kódu:
<!--<ClaimsProviders>-->
...
<ClaimsProvider>
<!-- The following Domain element allows this profile to be used if the request comes with domain_hint
query string parameter, e.g. domain_hint=facebook.com -->
<Domain>facebook.com</Domain>
<DisplayName>Facebook</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="Facebook-OAUTH">
<!-- The text in the following DisplayName element is shown to the user on the claims provider
selection screen. -->
<DisplayName>Facebook</DisplayName>
<Protocol Name="OAuth2" />
<Metadata>
<Item Key="ProviderName">facebook</Item>
<Item Key="authorization_endpoint">https://www.facebook.com/dialog/oauth</Item>
<Item Key="AccessTokenEndpoint">https://graph.facebook.com/oauth/access_token</Item>
<Item Key="HttpBinding">GET</Item>
<Item Key="UsePolicyInRedirectUri">0</Item>
<Item Key="client_id">facebook-app-id</Item>
<Item Key="scope">email public_profile</Item>
<Item Key="ClaimsEndpoint">https://graph.facebook.com/me?fields=id,first_name,last_name,name,email</Item>
<Item Key="AccessTokenResponseFormat">json</Item>
</Metadata>
<CryptographicKeys>
<Key Id="client_secret" StorageReferenceId="facebook-policy-key" />
</CryptographicKeys>
<InputClaims />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="id" />
<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
<OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
<OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="facebook.com" AlwaysUseDefaultValue="true" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
<OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
<OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
</OutputClaimsTransformations>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<!--</ClaimsProviders>-->
Nahrazení:
facebook-app-ids hodnotou FacebookuappID, kterou jste získali v kroku 1.facebook-policy-keys názvem klíče zásad Facebooku, který jste získali v kroku 2.
Všimněte si transformací deklarací identity, které jsme definovali v kroku 3.2 v kolekci OutputClaimsTransformations .
Krok 3.4 – Vytvoření technických profilů Microsoft Entra
Stejně jako při přihlášení pomocí místního účtu musíte nakonfigurovat technické profily Microsoft Entra, které používáte pro připojení k úložišti Microsoft Entra ID, k ukládání nebo čtení uživatelského účtu na sociální síti.
ContosoCustomPolicy.XMLV souboru vyhledejteAAD-UserUpdatetechnický profil a přidejte nový technický profil pomocí následujícího kódu:<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId"> <DisplayName>Azure Active Directory technical profile for handling social accounts</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> <Metadata> <Item Key="Operation">Write</Item> <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item> </Metadata> <CryptographicKeys> <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" /> </CryptographicKeys> <InputClaims> <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" /> </InputClaims> <PersistedClaims> <!-- Required claims --> <PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" /> <PersistedClaim ClaimTypeReferenceId="userPrincipalName" /> <PersistedClaim ClaimTypeReferenceId="mailNickName" DefaultValue="unknown" /> <PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" /> <!-- Optional claims --> <PersistedClaim ClaimTypeReferenceId="givenName" /> <PersistedClaim ClaimTypeReferenceId="surname" /> </PersistedClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="objectId" /> <OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" /> </OutputClaims> </TechnicalProfile>Přidali jsme nový technický profil
AAD-UserWriteUsingAlternativeSecurityIdMicrosoft Entra, který do Microsoft Entra ID zapíše nový sociální účet.Nahraďte B2C_1A_TokenSigningKeyContainer podpisovým klíčem tokenu, který jste vytvořili v části Konfigurace podepisování.
ContosoCustomPolicy.XMLDo souboru přidejte další technický profil Microsoft Entra zaAAD-UserWriteUsingAlternativeSecurityIdtechnický profil pomocí následujícího kódu:<TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId"> <DisplayName>Azure Active Directory</DisplayName> <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" /> <Metadata> <Item Key="Operation">Read</Item> <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item> </Metadata> <CryptographicKeys> <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" /> </CryptographicKeys> <InputClaims> <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" /> </InputClaims> <OutputClaims> <!-- Required claims --> <OutputClaim ClaimTypeReferenceId="objectId" /> <!-- Optional claims --> <OutputClaim ClaimTypeReferenceId="userPrincipalName" /> <OutputClaim ClaimTypeReferenceId="displayName" /> <OutputClaim ClaimTypeReferenceId="givenName" /> <OutputClaim ClaimTypeReferenceId="surname" /> </OutputClaims> </TechnicalProfile>Přidali jsme nový technický profil
AAD-UserReadUsingAlternativeSecurityIdMicrosoft Entra, který čte nový sociální účet z ID Microsoft Entra. PoužíváalternativeSecurityIdse jako jedinečný identifikátor pro účet sociální sítě.Nahraďte B2C_1A_TokenSigningKeyContainer podpisovým klíčem tokenu, který jste vytvořili v části Konfigurace podepisování.
Krok 3.5 – Konfigurace definice obsahu
Po přihlášení uživatele můžete některé informace shromáždit pomocí technického profilu s vlastním uplatněním. Proto je potřeba nakonfigurovat definici obsahu pro technický profil s vlastním kontrolním výrazem.
ContosoCustomPolicy.XML V souboru vyhledejte ContentDefinitions prvek a pak přidejte do kolekce novou definici ContentDefinitions obsahu pomocí následujícího kódu:
<ContentDefinition Id="socialAccountsignupContentDefinition">
<LoadUri>~/tenant/templates/AzureBlue/selfAsserted.cshtml</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.7</DataUri>
<Metadata>
<Item Key="DisplayName">Collect information from user page alongside those from social Idp.</Item>
</Metadata>
</ContentDefinition>
Tuto definici obsahu používáme jako metadata v technickém profilu s vlastním uplatněním v dalším kroku (krok 3.6).
Krok 3.6 – Konfigurace technického profilu s vlastním kontrolním výrazem
Technický profil, který jste v tomto kroku nakonfigurovali, se používá ke shromažďování dalších informací od uživatele nebo aktualizaci podobných informací získaných ze sociálního účtu.
ContosoCustomPolicy.XML V souboru vyhledejte ClaimsProviders oddíl a pak pomocí následujícího kódu přidejte nového zprostředkovatele deklarací identity:
<!--<ClaimsProviders>-->
...
<ClaimsProvider>
<DisplayName>Self Asserted for social sign in</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="SelfAsserted-Social">
<DisplayName>Collect more info during social signup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ContentDefinitionReferenceId">socialAccountsignupContentDefinition</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<InputClaims>
<!-- These claims ensure that any values retrieved in the previous steps (e.g. from an external IDP) are prefilled.
Note that some of these claims may not have any value, for example, if the external IDP did not provide any of
these values, or if the claim did not appear in the OutputClaims section of the IDP.
In addition, if a claim is not in the InputClaims section, but it is in the OutputClaims section, then its
value will not be prefilled, but the user will still be prompted for it (with an empty value). -->
<InputClaim ClaimTypeReferenceId="displayName" />
<InputClaim ClaimTypeReferenceId="givenName" />
<InputClaim ClaimTypeReferenceId="surname" />
</InputClaims>
<!---User will be asked to input or update these values-->
<DisplayClaims>
<DisplayClaim ClaimTypeReferenceId="displayName"/>
<DisplayClaim ClaimTypeReferenceId="givenName"/>
<DisplayClaim ClaimTypeReferenceId="surname"/>
</DisplayClaims>
<OutputClaims>
<!-- These claims are not shown to the user because their value is obtained through the "ValidationTechnicalProfiles"
referenced below, or a default value is assigned to the claim. A claim is only shown to the user to provide a
value if its value cannot be obtained through any other means. -->
<OutputClaim ClaimTypeReferenceId="objectId" />
<OutputClaim ClaimTypeReferenceId="newUser" />
<!---<OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />-->
<!-- Optional claims. These claims are collected from the user and can be modified. If a claim is to be persisted in the directory after having been
collected from the user, it needs to be added as a PersistedClaim in the ValidationTechnicalProfile referenced below, i.e.
in AAD-UserWriteUsingAlternativeSecurityId. -->
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
</OutputClaims>
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
</ValidationTechnicalProfiles>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
<!--</ClaimsProviders>-->
Zprostředkovatel deklarací identity, který jsme přidali, obsahuje technický profil SelfAsserted-Socials vlastním uplatněním. Technický profil s vlastním uplatněním používá technický profil technického AAD-UserWriteUsingAlternativeSecurityId profilu jako ověřovací technický profil. Technický profil se AAD-UserWriteUsingAlternativeSecurityId tedy spustí, když uživatel vybere tlačítko Pokračovat (viz snímek obrazovky v kroku 7).
Všimněte si také, že jsme přidali definici obsahu, socialAccountsignupContentDefinitionkterou jsme nakonfigurovali v kroku 3.5 v části metadat.
Krok 4 – aktualizace kroků orchestrace cesty uživatele
ContosoCustomPolicy.XML V souboru vyhledejte HelloWorldJourney cestu uživatele a nahraďte všechny kroky orchestrace postupem uvedeným v následujícím kódu:
<!--<OrchestrationSteps>-->
...
<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp">
<ClaimsProviderSelections>
<ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
</ClaimsProviderSelections>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="FacebookExchange"
TechnicalProfileReferenceId="Facebook-OAUTH" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- For social IDP authentication, attempt to find the user account in the
directory. -->
<OrchestrationStep Order="3" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- Show self-asserted page only if the directory does not have the user account
already (i.e. we don't have an objectId). -->
<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>
<OrchestrationStep Order="5" 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="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
<!--</OrchestrationSteps>-->
V orchestraci jsme použili odkaz na technické profily, které uživateli umožňují přihlásit se pomocí sociálních účtů.
Při spuštění vlastních zásad:
Orchestrace – krok 1 – tento krok obsahuje prvek, který obsahuje
ClaimsProviderSelectionsseznam dostupných možností přihlašování, ze kterých si uživatel může vybrat. V tomto případě máme jenom jednu možnost,FacebookExchangetakže když se zásady spustí, uživatelé se přesouvají přímo do Facebook.com v kroku 2, jak je znázorněno atributemTargetClaimsExchangeId.Orchestrace Krok 2 – Spustí se
Facebook-OAUTHtechnický profil, takže se uživatel přesměruje na Facebook, aby se přihlásil.Orchestrace – Krok 3 – V kroku 3
AAD-UserReadUsingAlternativeSecurityIdse technický profil pokusí přečíst uživatelský sociální účet z úložiště Microsoft Entra ID. Pokud se najde sociální účet,objectIdvrátí se jako výstupní deklarace identity.Orchestrace – Krok 4 – Tento krok se spustí, pokud uživatel ještě neexistuje (
objectIdneexistuje). Zobrazí formulář, který shromažďuje další informace od uživatele nebo aktualizuje podobné informace získané ze sociálního účtu.Orchestrace Krok 5 – Tento krok se spustí, pokud uživatel ještě neexistuje (
objectIdneexistuje), takžeAAD-UserWriteUsingAlternativeSecurityIdtechnický profil se spustí pro zápis účtu sociální sítě do Microsoft Entra ID.Orchestrace – Krok 6 – Nakonec se krok 6 sestaví a vrátí token JWT na konci spuštění zásady.
Krok 5 – Aktualizace výstupních deklarací identity předávající strany
ContosoCustomPolicy.XML V souboru vyhledejte RelyingParty prvek a pak nahraďte všechny výstupní kolekce deklarací identity následujícím kódem:
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" />
Přidali jsme zprostředkovatele identity (identityProvider) jako výstupní deklaraci identity, takže se zahrne do tokenu JWT vráceného do aplikace předávající strany.
Krok 6 : Nahrání zásad
Postupujte podle kroků v části Nahrání souboru vlastních zásad a nahrajte soubor zásad. Pokud nahráváte soubor se stejným názvem jako soubor, který už je na portálu, nezapomeňte vybrat Možnost Přepsat vlastní zásadu, pokud už existuje.
Krok 7 – Testování zásad
Postupujte podle kroků v části Otestování vlastních zásad a otestujte vlastní zásady.
Budete přesměrováni na přihlašovací stránku Facebooku. Zadejte svoje přihlašovací údaje pro Facebook a pak vyberte Přihlásit se. Přímo vás přesměrujeme na Facebook, jak ho nastavíme, takže v našich krocích orchestrace nemáme více možností přihlášení, ze kterých si můžeme vybrat. Obvykle byste v aplikaci přidali tlačítko, jako je Přihlásit se přes Facebook, které při výběru spustí zásadu.
Pokud tuto zásadu spustíte poprvé (účet sociální sítě ještě v úložišti Microsoft Entra neexistuje), zobrazí se snímek obrazovky, například snímek obrazovky, který je zobrazený níže. Tuto obrazovku neuvidíte v následných spuštěních zásad, protože účet sociální sítě už v úložišti Microsoft Entra existuje.
Zadejte nebo aktualizujte zobrazované jméno, dané jméno a příjmení a pak vyberte tlačítko Pokračovat .
Po dokončení provádění zásady budete přesměrováni na https://jwt.msa zobrazí se dekódovaný token JWT. Vypadá podobně jako následující fragment kódu tokenu JWT:
{
"typ": "JWT",
"alg": "RS256",
"kid": "pxLOMWFgP4T..."
}.{
...
"acr": "b2c_1a_contosocustompolicy",
...
"given_name": "Maurice",
"family_name": "Paulet",
"name": "Maurice Paulet",
"email": "maurice.p@contoso.com",
"idp": "facebook.com"
}.[Signature]
Všimněte si zprostředkovatele identity, "idp": "facebook.com"který je součástí tokenu JWT.
Kombinované místní a sociální přihlášení
V tomto článku kroky orchestrace cesty uživatele odkazují pouze na technické profily, které uživateli umožňují přihlásit se pomocí účtu na sociálních sítích. Kroky orchestrace můžeme upravit tak, aby se uživatel mohl přihlásit pomocí místního účtu nebo účtu sociální sítě. Uděláte to tak, že první prvek kroku ClaimsProviderSelections orchestrace vypíše možnosti přihlášení, které má uživatel k dispozici.
Ke přidání kombinovaného místního a sociálního účtu použijte následující postup:
ContosoCustomPolicy.XMLV souboru vyhledejteAccountTypeInputCollectortechnický profil s vlastním uplatněním a potom přidejteauthenticationSourcedeklaraci identity do jeho výstupní kolekce deklarací identity pomocí následujícího kódu:<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />UserJourneysV části přidejte novou cestuLocalAndSocialSignInAndSignUpuživatele pomocí následujícího kódu:<!--<UserJourneys>--> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps> <!--Orchestration steps will be added here--> </OrchestrationSteps> </UserJourney> <!--</UserJourneys>-->Na cestě uživatele, kterou jste vytvořili,
LocalAndSocialSignInAndSignUppřidejte kroky orchestrace pomocí následujícího kódu:<!--<UserJourneys> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps>--> <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition"> <ClaimsProviderSelections> <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" /> <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" /> </ClaimsProviderSelections> <ClaimsExchanges> <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" /> </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="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" /> <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/> </ClaimsExchanges> </OrchestrationStep> <!--For Local sign in option start--> <OrchestrationStep Order="3" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="true"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>accountType</Value> <Value>work</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>socialIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="4" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="true"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>socialIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" /> </ClaimsExchanges> </OrchestrationStep> <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="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/> </ClaimsExchanges> </OrchestrationStep> <!--For Local sign in option end--> <!--For social sign in option start--> <!-- For social IDP authentication, attempt to find the user account in the directory. --> <OrchestrationStep Order="6" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>localIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" /> </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). --> <OrchestrationStep Order="7" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="true"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>localIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="8" Type="ClaimsExchange"> <Preconditions> <Precondition Type="ClaimsExist" ExecuteActionsIf="true"> <Value>objectId</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> <Value>authenticationSource</Value> <Value>localIdpAuthentication</Value> <Action>SkipThisOrchestrationStep</Action> </Precondition> </Preconditions> <ClaimsExchanges> <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" /> </ClaimsExchanges> </OrchestrationStep> <!--For social sign in option end--> <OrchestrationStep Order="9" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="10" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" /> <!-- </OrchestrationSteps> </UserJourney> </UserJourneys>-->V prvním kroku určíme možnosti, ze které si uživatel musí vybrat z cesty, místního nebo sociálního ověřování. V následujících krocích používáme předpoklady ke sledování možnosti, kterou uživatel vybral, nebo fázi cesty, ve které je uživatel. Deklarace identity například používáme
authenticationSourcek rozlišení cesty místního ověřování a cesty sociálního ověřování.RelyingPartyV části změňte VýchozíUserJourneyReferenceIdnaLocalAndSocialSignInAndSignUpPomocí postupu v kroku 6 a 7 nahrajte a spusťte zásady. Po spuštění zásady se zobrazí obrazovka podobná následujícímu snímku obrazovky.
Můžete si všimnout, že se uživatel může zaregistrovat nebo přihlásit pomocí místního účtu nebo účtu sociální sítě.
Další kroky
- Přečtěte si další informace o definování technického profilu OAuth2 ve vlastních zásadách Azure Active Directory B2C.
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro