Configurer un flux d’inscription et de connexion avec un compte local en utilisant une stratégie Azure Active Directory B2C personnalisée
Dans l’article Configurer un flux d’inscription et de connexion à l’aide de la stratégie personnalisée Azure Active Directory B2C, nous avons configuré le flux de connexion pour un compte local à l’aide d’Azure Active Directory B2C (Azure AD B2C).
Dans cet article, nous ajoutons un flux de connexion pour un compte externe, tel qu’un compte social de type Facebook. Dans ce cas, Azure AD B2C permet à un utilisateur de se connecter à votre application à l’aide d’informations d’identification provenant d’un fournisseur d’identité social (IdP) externe.
Pour les comptes locaux, le compte d’utilisateur est identifié de manière unique à l’aide de l’élément objectIdattribut utilisateur. Pour le fournisseur d’identité social externe, nous utilisons un attribut utilisateur alternativeSecurityId bien qu’un élément objectId existe encore.
Prérequis
Si vous n’en avez pas, créez un locataire Azure AD B2C qui est lié à votre abonnement Azure.
Inscrivez une application web et activez l’octroi implicite de jeton d’ID. Pour l’URI de redirection, utilisez https://jwt.ms.
Visual Studio Code (VS Code) doit être installé sur votre ordinateur.
Effectuez les étapes décrites dans Configurer un flux d’inscription et de connexion pour un compte local en utilisant une stratégie Azure Active Directory B2C personnalisée. Cet article fait partie de la série de guides pratiques Créer et exécuter vos propres stratégies personnalisées.
Notes
Cet article fait partie de la série de guides pratiques Créer et exécuter vos propres stratégies personnalisées dans Azure Active Directory B2C. Nous vous recommandons de commencer cette série par le premier article.
Étape 1 : créer une application Facebook
Suivez les étapes décrites dans Créer une application Facebook pour obtenir un ID d’application et un secret d’application Facebook. Ignorez les prérequis et le reste des étapes de l’article Configurer l’inscription et se connecter avec un compte Facebook.
Étape 2 : créer une clé de stratégie Facebook
Suivez les étapes décrites dans Créer une clé de stratégie qui stockent une clé de stratégie dans votre locataire Azure AD B2C. Ignorez les prérequis et le reste des étapes de l’article Configurer l’inscription et se connecter avec un compte Facebook.
Étape 3 : configurer une connexion avec Facebook
Pour configurer une connexion avec Facebook, vous devez effectuer les étapes suivantes :
- Déclarer d’autres revendications
- Définissez d’autres transformations de revendications pour faciliter les manipulations de revendications tel qu’en créant
AlternativeSecurityId. - Configurer un fournisseur de revendications Facebook
- Configurez des profils techniques Microsoft Entra pour lire et écrire le compte social à partir de et vers la base de données Microsoft Entra.
- Configurez un profil technique autodéclaré (pour accepter des entrées supplémentaires de l’utilisateur ou mettre à jour les détails de l’utilisateur) et sa définition de contenu.
Étape 3.1 : déclarer d’autres revendications
Dans le fichier ContosoCustomPolicy.XML, recherchez la section ClaimsSchema, puis déclarez d’autres revendications en utilisant le code suivant :
<!--<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>-->
Étape 3.2 : définir des transformations de revendications
Dans le fichier ContosoCustomPolicy.XML, recherchez l’élément ClaimsTransformations et ajoutez des transformations de revendications à l’aide du code suivant :
<!--<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>-->
Nous avons défini trois transformations de revendications que nous utilisons pour générer des valeurs pour les revendications alternativeSecurityId et userPrincipalName. Ces ClaimsTransformations sont appelées dans le profil technique OAuth2 à l’étape 3.3.
Étape 3.3 : configurer un fournisseur de revendications Facebook
Pour permettre aux utilisateurs de se connecter avec un compte Facebook, vous devez définir le compte comme fournisseur de revendications avec lequel Azure AD B2C peut communiquer à travers un point de terminaison. Vous pouvez définir un compte Facebook en tant que fournisseur de revendications.
Dans le fichier ContosoCustomPolicy.XML, recherchez l’élément ClaimsProviders et ajoutez un nouveau fournisseur de revendications à l’aide du code suivant :
<!--<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>-->
Remplacez :
facebook-app-idavec la valeurappIDde Facebook que vous avez obtenue à l’étape 1.facebook-policy-keyavec le nom de la clé de stratégie Facebook que vous avez obtenue à l’étape 2.
Notez les transformations de revendications que nous avons définies à l’étape 3.2 de la collection OutputClaimsTransformations.
Étape 3.4 – Créer des profils techniques Microsoft Entra
Tout comme dans la connexion à un compte local, vous devez configurer les Profils techniques Microsoft Entra que vous utilisez pour vous connecter au stockage Microsoft Entra ID, afin de stocker ou de lire un compte social utilisateur.
Dans le fichier
ContosoCustomPolicy.XML, localisez le profil techniqueAAD-UserUpdatepuis ajoutez un nouveau profil technique en utilisant le code suivant :<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>Nous avons ajouté un nouveau profil technique Microsoft Entra
AAD-UserWriteUsingAlternativeSecurityIdqui écrit un nouveau compte social dans Microsoft Entra ID.Remplacez B2C_1A_TokenSigningKeyContainer par la clé de signature de jeton que vous avez créée dans Configurer la signature.
Dans le fichier
ContosoCustomPolicy.XML, ajoutez un autre profil technique Microsoft Entra après le profil techniqueAAD-UserWriteUsingAlternativeSecurityIden utilisant le code suivant :<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>Nous avons ajouté un nouveau profil technique Microsoft Entra
AAD-UserReadUsingAlternativeSecurityIdqui lit un nouveau compte social à partir de Microsoft Entra ID. Il utilisealternativeSecurityIdcomme identificateur unique pour le compte social.Remplacez B2C_1A_TokenSigningKeyContainer par la clé de signature de jeton que vous avez créée dans Configurer la signature.
Étape 3.5 : configurer des définitions de contenu
Une fois qu’un utilisateur s’est connecté, vous pouvez collecter des informations auprès de lui à l’aide d’un profil technique auto-déclaré. Vous devez donc configurer une définition de contenu pour le profil technique auto-déclaré.
Dans le fichier ContosoCustomPolicy.XML, recherchez l’élément ContentDefinitions, puis ajoutez une nouvelle définition de contenu dans la collection ContentDefinitions à l’aide du code suivant :
<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>
Nous utilisons cette définition de contenu comme métadonnées dans un profil technique autodéclaré à l’étape suivante (étape 3.6).
Étape 3.6 : configurer un profil technique autodéclaré
Le profil technique autodéclaré que vous configurez dans cette étape est utilisé pour collecter plus d’informations auprès de l’utilisateur ou mettre à jour des informations similaires obtenues à partir du compte social.
Dans le fichier ContosoCustomPolicy.XML, recherchez la section ClaimsProviders, puis ajoutez un nouveau fournisseur de revendications à l’aide du code suivant :
<!--<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>-->
Le fournisseur de revendications que nous avons ajouté contient un profil technique autodéclaré, SelfAsserted-Social. Le profil technique autodéclaré utilise le profil technique AAD-UserWriteUsingAlternativeSecurityId comme profil technique de validation. Par conséquent, le profil technique AAD-UserWriteUsingAlternativeSecurityId s’exécute lorsque l’utilisateur sélectionne le bouton Continuer (voir capture d’écran à l’étape 7).
Notez également que nous avons ajouté la définition de contenu, socialAccountsignupContentDefinition, que nous avons configurée à l’étape 3.5, dans la section métadonnées.
Étape 4 : mettre à jour les étapes d’orchestration du parcours utilisateur
Dans le fichier ContosoCustomPolicy.XML, recherchez le parcours utilisateur HelloWorldJourney et remplacez toutes les étapes d’orchestration par les étapes décrites dans le code suivant :
<!--<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>-->
Dans l’orchestration, nous avons utilisé l’élément Faire référence à des profils techniques qui permettent à un utilisateur de se connecter à l’aide d’un compte social.
Lorsque la stratégie personnalisée s’exécute :
Étape 1 de l’orchestration : cette étape inclut un élément
ClaimsProviderSelectionsqui répertorie les options de connexion disponibles parmi lesquelles un utilisateur peut choisir. Dans ce cas, nous n’avons qu’une seule option,FacebookExchange. Ainsi, lorsque la stratégie s’exécute, les utilisateurs sont directement dirigés vers Facebook.com à l’étape 2, comme indiqué par l’attributTargetClaimsExchangeId.Étape 2 de l’orchestration : le profil technique
Facebook-OAUTHs’exécute, de sorte que l’utilisateur est redirigé vers Facebook pour la connexion.Étape 3 de l’orchestration : à l’étape 3, le profil technique
AAD-UserReadUsingAlternativeSecurityIds’exécute pour tenter de lire le compte social de l’utilisateur à partir du stockage Microsoft Entra ID. Si le compte social est trouvé,objectIdest retourné en tant que revendication de sortie.Étape 4 de l’orchestration : cette étape s’exécute si l’utilisateur n’existe pas encore (
objectIdn’existe pas). Elle affiche le formulaire qui collecte d’autres informations auprès de l’utilisateur ou met à jour des informations similaires obtenues à partir du compte social.Étape d'orchestration 5 – Cette étape s'exécute si l'utilisateur n'existe pas déjà (
objectIdn'existe pas), de sorte que le profil techniqueAAD-UserWriteUsingAlternativeSecurityIds'exécute pour écrire le compte social dans Microsoft Entra ID.Étape 6 de l’orchestration : enfin, l’étape 6 assemble et retourne le jeton JWT à la fin de l’exécution de la stratégie.
Étape 5 : mettre à jour les revendications de sortie de la partie de confiance
Dans le fichier ContosoCustomPolicy.XML, recherchez l’élément RelyingParty, puis remplacez toute la collection de revendications de sortie par le code suivant :
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" />
Nous avons ajouté le fournisseur d’identité (identityProvider) en tant que revendication de sortie. Il sera donc inclus dans le jeton JWT retourné à l’application de la partie de confiance.
Étape 6 : charger une stratégie
Suivez les étapes décrites dans Charger un fichier de stratégie personnalisée pour charger votre fichier de stratégie. Si vous chargez un fichier portant le même nom que celui déjà présent dans le portail, veillez à sélectionner Remplacer la stratégie personnalisée si elle existe déjà.
Étape 7 : tester la stratégie
Suivez les étapes décrites dans Tester la stratégie personnalisée pour tester votre stratégie personnalisée.
Vous êtes redirigé vers une page de connexion Facebook. Entrez vos informations d’identification Facebook, puis sélectionnez Se connecter. Vous êtes directement redirigé vers Facebook, car nous le définissons de cette manière dans nos étapes d’orchestration, car nous n’avons pas plusieurs options de connexion à choisir. En règle générale, dans une application, vous ajoutez un bouton comme Se connecter avec Facebook qui, lorsqu’il est sélectionné, exécute la stratégie.
S’il s’agit de la première exécution de cette stratégie (le compte social n’existe pas encore dans le stockage Microsoft Entra), vous voyez une capture d’écran telle que celle illustrée ci-dessous. Vous ne verrez pas cet écran dans les exécutions de stratégie suivantes, car le compte social existe déjà dans le stockage Microsoft Entra.
Entrez ou mettez à jour le Nom d’affichage, le Prénom et le Nom, puis sélectionnez le bouton Continuer.
Une fois l’exécution de la stratégie terminée, vous êtes redirigé vers https://jwt.ms et le jeton JWT décodé s’affiche. Il ressemble à l’extrait de jeton JWT suivant :
{
"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]
Notez que le fournisseur d’identité, "idp": "facebook.com", a été inclus dans le jeton JWT.
Une connexion locale et sociale combinée
Dans cet article, nos étapes d’orchestration du parcours utilisateur référencent uniquement les profils techniques qui permettent à un utilisateur de se connecter à l’aide d’un compte social. Nous pouvons modifier les étapes d’orchestration pour permettre à un utilisateur de se connecter en utilisant un compte local ou un compte social. Pour ce faire, l’élément ClaimsProviderSelections de la première étape d’orchestration répertorie les options de connexion disponibles pour l’utilisateur.
Procédez comme suit pour ajouter un compte local et social combiné :
Dans le fichier
ContosoCustomPolicy.XML, recherchez le profil techniqueAccountTypeInputCollectorautodéclaré, puis ajoutez une revendicationauthenticationSourcedans sa collection de revendications de sortie à l’aide du code suivant :<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />Dans la section
UserJourneys, ajoutez un nouveau parcours utilisateurLocalAndSocialSignInAndSignUpen utilisant le code suivant :<!--<UserJourneys>--> ... <UserJourney Id="LocalAndSocialSignInAndSignUp"> <OrchestrationSteps> <!--Orchestration steps will be added here--> </OrchestrationSteps> </UserJourney> <!--</UserJourneys>-->Dans le parcours utilisateur que vous avez créé,
LocalAndSocialSignInAndSignUp, ajoutez des étapes d’orchestration à l’aide du code suivant :<!--<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>-->Lors de la première étape, nous spécifions les options qu’un utilisateur doit choisir dans son parcours, l’authentification locale ou sociale. Lors des étapes suivantes, nous utilisons des conditions préalables pour suivre l’option choisie par l’utilisateur ou l’étape du parcours auquel il se trouve. Par exemple, nous utilisons la revendication
authenticationSourcepour faire une distinction entre un parcours d’authentification local et un parcours d’authentification social.Dans la section
RelyingParty, remplacez DefaultUserJourneyReferenceIdparLocalAndSocialSignInAndSignUpUtilisez la procédure décrite à l’étape 6 et à l’étape 7 pour charger et exécuter votre stratégie. Après avoir exécuté la stratégie, un écran semblable à la capture d’écran suivante s’affiche.
Vous pouvez observer qu’un utilisateur peut s’inscrire ou se connecter en utilisant un compte local ou un compte social.
Étapes suivantes
- En savoir plus sur la façon de Définir un profil technique OAuth2 dans une stratégie Azure Active Directory B2C personnalisée.