Configurare un flusso di iscrizione e accesso con un account social usando criteri personalizzati di Azure Active Directory B2C
Nell'articolo Configurare un flusso di iscrizione e accesso usando i criteri personalizzati di Azure Active Directory B2C viene configurato il flusso di accesso per un account locale usando Azure Active Directory B2C (Azure AD B2C).
In questo articolo viene aggiunto un flusso di accesso per un account esterno, ad esempio un account social come Facebook. In questo caso, Azure AD B2C consente a un utente di accedere all'applicazione con le credenziali di un provider di identità di social networking esterno (IdP).
Per gli account locali, un account utente viene identificato in modo univoco usando l'attributo objectIdutente. Per IdP esterno, viene usato l'attributo alternativeSecurityId utente anche se objectId esiste ancora.
Prerequisiti
In assenza di un tenant, creare un tenant di Azure AD B2C collegato alla sottoscrizione di Azure.
Registrare un'applicazione Web e abilitare la concessione implicita del token ID. Per l'URI di reindirizzamento, usare https://jwt.ms.
Nel computer deve essere installato Visual Studio Code (VS Code ).
Completare i passaggi descritti in Configurare un flusso di iscrizione e accesso per l'account locale usando i criteri personalizzati di Azure Active Directory B2C. Questo articolo fa parte della serie di procedure per creare ed eseguire criteri personalizzati.
Nota
Questo articolo fa parte della serie di procedure Creare ed eseguire criteri personalizzati in Azure Active Directory B2C. È consigliabile iniziare questa serie dal primo articolo.
Passaggio 1 - Creare un'applicazione Facebook
Usare i passaggi descritti in Creare un'applicazione Facebook per ottenere l'ID app Facebook e il segreto dell'app. Ignorare i prerequisiti e il resto dei passaggi descritti nell'articolo Configurare l'iscrizione e accedere con un account Facebook.
Passaggio 2 - Creare la chiave dei criteri di Facebook
Usare i passaggi descritti in Creare la chiave dell'archivio chiavi di Facebook una chiave dei criteri nel tenant di Azure AD B2C. Ignorare i prerequisiti e il resto dei passaggi descritti nell'articolo Configurare l'iscrizione e accedere con un account Facebook.
Passaggio 3 - Configurare l'accesso con Facebook
Per configurare l'accesso con Facebook, è necessario seguire questa procedura:
- Dichiarare più attestazioni
- Definire altre trasformazioni delle attestazioni per facilitare la modifica delle attestazioni, ad esempio la creazione di
AlternativeSecurityId. - Configurare il provider di attestazioni Facebook
- Configurare i profili tecnici di Microsoft Entra per leggere e scrivere l'account social da e nel database Microsoft Entra.
- Configurare un profilo tecnico autocertificato (per accettare input aggiuntivi dall'utente o aggiornare i dettagli utente) e la relativa definizione di contenuto.
Passaggio 3.1 - Dichiarare altre attestazioni
ContosoCustomPolicy.XML Nel file individuare la ClaimsSchema sezione e quindi dichiarare altre attestazioni usando il codice seguente:
<!--<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>-->
Passaggio 3.2 - Definire le trasformazioni delle attestazioni
ContosoCustomPolicy.XML Nel file individuare l'elemento ClaimsTransformations e aggiungere trasformazioni delle attestazioni usando il codice seguente:
<!--<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>-->
Sono stati definiti tre trasformazioni di attestazioni, che vengono usate per generare valori per alternativeSecurityId le attestazioni e userPrincipalName . Queste attestazioniTransformations vengono richiamate nel profilo tecnico OAuth2 nel passaggio 3.3.
Passaggio 3.3 - Configurare il provider di attestazioni facebook
Per consentire agli utenti di accedere usando un account Facebook, è necessario definire l'account come provider di attestazioni con cui Azure AD B2C può comunicare tramite un endpoint. È possibile definire un account Facebook come provider di attestazioni.
Nel file individuare ClaimsProviders l'elemento ContosoCustomPolicy.XML aggiungere un nuovo provider di attestazioni usando il codice seguente:
<!--<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>-->
Sostituzione:
facebook-app-idcon il valore di FacebookappIDottenuto nel passaggio 1.facebook-policy-keycon il nome della chiave dei criteri di Facebook ottenuta nel passaggio 2.
Si notino le trasformazioni delle attestazioni definite nel passaggio 3.2 nella OutputClaimsTransformations raccolta.
Passaggio 3.4 - Creare profili tecnici di Microsoft Entra
Proprio come per l'accesso con un account locale, è necessario configurare i profili tecnici di Microsoft Entra, che si usano per connettersi all'archiviazione di Microsoft Entra ID, per archiviare o leggere un account social utente.
ContosoCustomPolicy.XMLNel file individuare ilAAD-UserUpdateprofilo tecnico e quindi aggiungere un nuovo profilo tecnico usando il codice seguente:<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>È stato aggiunto un nuovo profilo
AAD-UserWriteUsingAlternativeSecurityIdtecnico Microsoft Entra che scrive un nuovo account social in Microsoft Entra ID.Sostituire B2C_1A_TokenSigningKeyContainer con la chiave di firma del token creata in Configurare la firma.
ContosoCustomPolicy.XMLNel file aggiungere un altro profilo tecnico Microsoft Entra dopo ilAAD-UserWriteUsingAlternativeSecurityIdprofilo tecnico usando il codice seguente:<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>È stato aggiunto un nuovo profilo
AAD-UserReadUsingAlternativeSecurityIdtecnico Microsoft Entra che legge un nuovo account di social networking da Microsoft Entra ID.alternativeSecurityIdUsa come identificatore univoco per l'account social.Sostituire B2C_1A_TokenSigningKeyContainer con la chiave di firma del token creata in Configurare la firma.
Passaggio 3.5 - Configurare la definizione del contenuto
Dopo l'accesso di un utente, è possibile raccogliere alcune informazioni da tali utenti usando un profilo tecnico autocertificato. È quindi necessario configurare la definizione del contenuto per il profilo tecnico autocertivi.
ContosoCustomPolicy.XML Nel file individuare l'elemento ContentDefinitions e quindi aggiungere una nuova definizione di contenuto nella ContentDefinitions raccolta usando il codice seguente:
<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>
Questa definizione di contenuto viene usata come metadati in un profilo tecnico autocertivi nel passaggio successivo (passaggio 3.6).
Passaggio 3.6 - Configurare un profilo tecnico autocertificato
Il profilo tecnico autocertivo configurato in questo passaggio viene usato per raccogliere altre informazioni dall'utente o aggiornare informazioni simili ottenute dall'account di social networking.
ContosoCustomPolicy.XML Nel file individuare la ClaimsProviders sezione e quindi aggiungere un nuovo provider di attestazioni usando il codice seguente:
<!--<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>-->
Il provider di attestazioni aggiunto contiene un profilo tecnico autocertificato, SelfAsserted-Social. Il profilo tecnico autocertificato usa il AAD-UserWriteUsingAlternativeSecurityId profilo tecnico come profilo tecnico di convalida. Quindi, il AAD-UserWriteUsingAlternativeSecurityId profilo tecnico viene eseguito quando l'utente seleziona il pulsante Continua (vedere lo screenshot nel passaggio 7).
Si noti anche che è stata aggiunta la definizione del contenuto, socialAccountsignupContentDefinition, configurata nel passaggio 3.5 nella sezione metadati.
Passaggio 4- Aggiornare i passaggi di orchestrazione del percorso utente
ContosoCustomPolicy.XML Nel file individuare il HelloWorldJourney percorso utente e sostituire tutti i passaggi di orchestrazione con i passaggi illustrati nel codice seguente:
<!--<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>-->
Nell'orchestrazione è stato usato un riferimento ai profili tecnici che consentono a un utente di accedere usando un account social.
Quando vengono eseguiti i criteri personalizzati:
Passaggio di orchestrazione 1 : questo passaggio include un
ClaimsProviderSelectionselemento che elenca le opzioni di accesso disponibili tra cui un utente può scegliere. In questo caso, è disponibile una sola opzione,FacebookExchangequindi quando i criteri vengono eseguiti, gli utenti vengono portati direttamente a Facebook.com nel passaggio 2, come illustrato dall'attributoTargetClaimsExchangeId.Passaggio 2 dell'orchestrazione: viene eseguito il
Facebook-OAUTHprofilo tecnico, quindi l'utente viene reindirizzato a Facebook per accedere.Passaggio 3 dell'orchestrazione: nel passaggio 3 il
AAD-UserReadUsingAlternativeSecurityIdprofilo tecnico viene eseguito per provare a leggere l'account social utente dall'archiviazione microsoft Entra ID. Se viene trovato l'account di social networking,objectIdviene restituito come attestazione di output.Passaggio di orchestrazione 4 : questo passaggio viene eseguito se l'utente non esiste già (
objectIdnon esiste). Mostra il modulo che raccoglie altre informazioni dall'utente o aggiorna informazioni simili ottenute dall'account di social networking.Passaggio 5 dell'orchestrazione: questo passaggio viene eseguito se l'utente non esiste già (
objectIdnon esiste), quindi ilAAD-UserWriteUsingAlternativeSecurityIdprofilo tecnico viene eseguito per scrivere l'account di social networking in Microsoft Entra ID.Passaggio 6 dell'orchestrazione: infine, il passaggio 6 assembla e restituisce il token JWT alla fine dell'esecuzione del criterio.
Passaggio 5: Aggiornare le attestazioni di output della relying party
ContosoCustomPolicy.XML Nel file individuare l'elemento RelyingParty e quindi sostituire tutta la raccolta di attestazioni di output con il codice seguente:
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" />
Il provider di identità (identityProvider) è stato aggiunto come attestazione di output, quindi verrà incluso nel token JWT restituito all'applicazione relying party.
Passaggio 6 - Caricare i criteri
Seguire la procedura descritta in Caricare un file di criteri personalizzato per caricare il file dei criteri. Se si carica un file con lo stesso nome di quello già presente nel portale, assicurarsi di selezionare Sovrascrivi il criterio personalizzato, se già esistente.
Passaggio 7 - Testare i criteri
Seguire la procedura descritta in Testare i criteri personalizzati per testare i criteri personalizzati.
Si viene reindirizzati a una pagina di accesso di Facebook. Immettere le credenziali di Facebook e quindi selezionare Accedi. Si viene reindirizzati direttamente a Facebook durante l'impostazione in modo che nei passaggi di orchestrazione non siano disponibili più opzioni di accesso tra cui scegliere. In genere, in un'app è necessario aggiungere un pulsante come Accedi con Facebook, che, quando selezionato, esegue i criteri.
Se è la prima volta che si esegue questo criterio (l'account social non esiste già nell'archiviazione di Microsoft Entra), viene visualizzato uno screenshot come quello illustrato di seguito. Questa schermata non verrà visualizzata nelle esecuzioni dei criteri successive perché l'account di social networking esiste già nell'archiviazione di Microsoft Entra.
Immettere o aggiornare il nome visualizzato, il nome e il cognome e quindi il pulsante Continua .
Al termine dell'esecuzione del criterio, si viene reindirizzati a https://jwt.mse viene visualizzato un token JWT decodificato. È simile al frammento di token JWT seguente:
{
"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]
Si noti che il provider di identità, "idp": "facebook.com", è stato incluso nel token JWT.
Un accesso locale e social combinato
In questo articolo, i passaggi di orchestrazione del percorso utente fanno riferimento solo a profili tecnici che consentono a un utente di accedere usando un account social. È possibile modificare i passaggi di orchestrazione per consentire a un utente di accedere usando un account locale o un account social. A tale scopo, il primo elemento del passaggio di ClaimsProviderSelections orchestrazione elenca le opzioni di accesso disponibili per l'utente.
Usare la procedura seguente per aggiungere un account locale e social combinato:
ContosoCustomPolicy.XMLNel file individuare ilAccountTypeInputCollectorprofilo tecnico autocertificato e quindi aggiungereauthenticationSourcel'attestazione nella raccolta di attestazioni di output usando il codice seguente:<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />UserJourneysNella sezione aggiungere un nuovo percorsoLocalAndSocialSignInAndSignUputente usando il codice seguente:<!--<UserJourneys>--> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps> <!--Orchestration steps will be added here--> </OrchestrationSteps> </UserJourney> <!--</UserJourneys>-->Nel percorso utente creato aggiungere
LocalAndSocialSignInAndSignUpi passaggi di orchestrazione usando il codice seguente:<!--<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>-->Nel primo passaggio si specificano le opzioni che un utente deve scegliere nel percorso, nell'autenticazione locale o sociale. Nei passaggi seguenti si usano le precondizioni per tenere traccia dell'opzione selezionata dall'utente o dalla fase del percorso in cui si trova l'utente. Ad esempio, si usa l'attestazione
authenticationSourceper distinguere tra un percorso di autenticazione locale e un percorso di autenticazione social.RelyingPartyNella sezione modificare DefaultUserJourney inReferenceIdLocalAndSocialSignInAndSignUpUsare la procedura descritta nel passaggio 6 e nel passaggio 7 per caricare ed eseguire i criteri. Dopo aver eseguito i criteri, verrà visualizzata una schermata simile alla schermata seguente.
È possibile osservare che un utente può iscriversi o accedere usando un account locale o un account di social networking.
Passaggi successivi
- Altre informazioni su come definire un profilo tecnico OAuth2 in un criterio personalizzato di Azure Active Directory B2C.