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 objectId
utente. Per IdP esterno, viene usato l'attributo alternativeSecurityId
utente anche se objectId
esiste ancora.
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.
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.
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.
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.
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>-->
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.
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-id
con il valore di FacebookappID
ottenuto nel passaggio 1.facebook-policy-key
con 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.
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.XML
Nel file individuare ilAAD-UserUpdate
profilo 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-UserWriteUsingAlternativeSecurityId
tecnico 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.XML
Nel file aggiungere un altro profilo tecnico Microsoft Entra dopo ilAAD-UserWriteUsingAlternativeSecurityId
profilo 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-UserReadUsingAlternativeSecurityId
tecnico Microsoft Entra che legge un nuovo account di social networking da Microsoft Entra ID.alternativeSecurityId
Usa come identificatore univoco per l'account social.Sostituire B2C_1A_TokenSigningKeyContainer con la chiave di firma del token creata in Configurare la firma.
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).
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.
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
ClaimsProviderSelections
elemento che elenca le opzioni di accesso disponibili tra cui un utente può scegliere. In questo caso, è disponibile una sola opzione,FacebookExchange
quindi 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-OAUTH
profilo tecnico, quindi l'utente viene reindirizzato a Facebook per accedere.Passaggio 3 dell'orchestrazione: nel passaggio 3 il
AAD-UserReadUsingAlternativeSecurityId
profilo tecnico viene eseguito per provare a leggere l'account social utente dall'archiviazione microsoft Entra ID. Se viene trovato l'account di social networking,objectId
viene restituito come attestazione di output.Passaggio di orchestrazione 4 : questo passaggio viene eseguito se l'utente non esiste già (
objectId
non 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à (
objectId
non esiste), quindi ilAAD-UserWriteUsingAlternativeSecurityId
profilo 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.
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.
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.
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.
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.XML
Nel file individuare ilAccountTypeInputCollector
profilo tecnico autocertificato e quindi aggiungereauthenticationSource
l'attestazione nella raccolta di attestazioni di output usando il codice seguente:<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />
UserJourneys
Nella sezione aggiungere un nuovo percorsoLocalAndSocialSignInAndSignUp
utente usando il codice seguente:<!--<UserJourneys>--> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps> <!--Orchestration steps will be added here--> </OrchestrationSteps> </UserJourney> <!--</UserJourneys>-->
Nel percorso utente creato aggiungere
LocalAndSocialSignInAndSignUp
i 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
authenticationSource
per distinguere tra un percorso di autenticazione locale e un percorso di autenticazione social.RelyingParty
Nella sezione modificare DefaultUserJourney inReferenceId
LocalAndSocialSignInAndSignUp
Usare 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.
- Altre informazioni su come definire un profilo tecnico OAuth2 in un criterio personalizzato di Azure Active Directory B2C.