Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.
Dans l'article Configurer un flux d'inscription et de connexion à l'aide d'une stratégie personnalisée d'Azure Active Directory B2C, nous avons configuré le flux de connexion pour un compte local en utilisant 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 comme Facebook. Dans ce cas, Azure AD B2C permet à un utilisateur de se connecter à votre application avec des informations d’identification provenant d’un fournisseur d’identité sociale externe (IDP).
Pour les comptes locaux, un compte d’utilisateur est identifié de manière unique à l’aide de objectId utilisateur. Pour le fournisseur d’identité social externe, nous utilisons un attribut utilisateur alternativeSecurityId bien qu’un élément objectId existe encore.
Conditions préalables
Si vous n’en avez pas encore, créez un locataire Azure AD B2C lié à votre abonnement Azure.
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 à l’aide d’une stratégie personnalisée Azure Active Directory B2C. Cet article fait partie de Create and run your own custom policies how-to guide series.
Remarque
Cet article fait partie de la série de guides de création et d’exécution de vos propres stratégies personnalisées dans Azure Active Directory B2C. Nous vous recommandons de commencer cette série à partir du premier article.
Étape 1 - Créer une application Facebook
Suivez les étapes décrites dans Créer une application Facebook pour obtenir l’ID d’application Facebook et le secret de l’application. Ignorez les prérequis et le reste des étapes de l’article Configurer l’inscription et la connexion avec un compte Facebook.
Étape 2 - Créer une clé de stratégie Facebook
Suivez les étapes décrites dans Créer la clé Facebook pour stocker 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 la connexion avec un compte Facebook.
Étape 3 : configurer la connexion avec Facebook
Pour configurer la connexion avec Facebook, vous devez effectuer les étapes suivantes :
- Déclarer d’autres revendications
- Définissez d'autres transformations de preuves pour faciliter les manipulations de preuves, comme la création de
AlternativeSecurityId. - Configurer le fournisseur de revendications Facebook
- Configurez les profils techniques Microsoft Entra pour lire et écrire le compte social depuis 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 ContosoCustomPolicy.XML fichier, recherchez la ClaimsSchema section, puis déclarez plus de revendications à l’aide du 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 déclarations alternativeSecurityId et userPrincipalName. Ces ClaimsTransformations sont appelées dans le profil technique OAuth2 à l’étape 3.3.
Étape 3.3 - Configurer le fournisseur de revendications Facebook
Pour permettre aux utilisateurs de se connecter à l’aide d’un compte Facebook, vous devez définir le compte en tant que fournisseur de revendications avec lequel Azure AD B2C peut communiquer via un point de terminaison. Vous pouvez définir un compte Facebook en tant que fournisseur de revendications.
Dans le fichier ContosoCustomPolicy.XML, localisez 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 valeur de FacebookappIDque 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.
Remarquez les transformations des revendications que nous avons définies à l’étape 3.2 de la OutputClaimsTransformations collection.
Étape 3.4 - Créer des profils techniques Microsoft Entra
Tout comme dans la connexion avec un compte local, vous devez configurer les profils techniques Microsoft Entra, que vous utilisez pour vous connecter au stockage d’ID Microsoft Entra, pour stocker ou lire un compte social d’utilisateur.
Dans le
ContosoCustomPolicy.XMLfichier, recherchez leAAD-UserReadprofil technique, puis ajoutez un nouveau profil technique ci-dessous à l’aide du 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
ContosoCustomPolicy.XMLfichier, ajoutez un autre profil technique Microsoft Entra après leAAD-UserWriteUsingAlternativeSecurityIdprofil technique à l’aide du 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 de Microsoft Entra
AAD-UserReadUsingAlternativeSecurityIdqui lit un nouveau compte social à partir de l'ID de Microsoft Entra. 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 la définition de contenu
Une fois qu’un utilisateur se connecte, vous pouvez collecter des informations à partir d’eux à l’aide d’un profil technique autodéclaré. Vous devez donc configurer la définition de contenu pour le profil technique autodé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 ContosoCustomPolicy.XML fichier, recherchez la ClaimsProviders section, 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 AAD-UserWriteUsingAlternativeSecurityId profil technique comme profil technique de validation. Par conséquent, le AAD-UserWriteUsingAlternativeSecurityId profil technique 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, socialAccountsignupContentDefinitionque 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 ContosoCustomPolicy.XML fichier, recherchez le HelloWorldJourney parcours utilisateur et remplacez toutes les étapes d’orchestration par les étapes indiquées 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 d’orchestration 1 : cette étape inclut un
ClaimsProviderSelectionsélément qui répertorie les options de connexion disponibles parmi lesquelles un utilisateur peut choisir. Dans ce cas, nous n’avons qu’une seule option.FacebookExchangePar conséquent, lorsque la stratégie s’exécute, les utilisateurs sont dirigés directement vers Facebook.com à l’étape 2, comme indiqué par l’attributTargetClaimsExchangeId.Orchestration Étape 2 : le
Facebook-OAUTHprofil technique s’exécute, de sorte que l’utilisateur est redirigé vers Facebook pour se connecter.Étape 3 de l’orchestration : à l’étape 3, le
AAD-UserReadUsingAlternativeSecurityIdprofil technique s’exécute pour essayer de lire le compte social de l'utilisateur à partir du stockage de Microsoft Entra ID. Si le compte social est trouvé,objectIdest renvoyé en tant qu'assertion de sortie.Étape d’orchestration 4 : cette étape s’exécute si l’utilisateur n’existe pas déjà (
objectIdn’existe pas). Il affiche le formulaire qui collecte plus d’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), leAAD-UserWriteUsingAlternativeSecurityIdprofil technique s’exécute pour écrire le compte social dans l’ID Microsoft Entra.Étape 6 de l’orchestration - Enfin, l’étape 6 assemble et retourne le 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 la collection de déclarations 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) comme réclamation de sortie. Il sera donc inclus dans le JWT retourné à l’application partie de confiance.
Étape 6 : charger une stratégie
Suivez les étapes décrites dans Charger le fichier de stratégie personnalisé 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 s’il 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 l’avons défini 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 ajouteriez un bouton tel que 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 déjà 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 complet, le nom donné et le nom de famille, puis sélectionnez Bouton Continuer .
Une fois l’exécution de la stratégie terminée, vous êtes redirigé vers https://jwt.ms, et vous voyez un JWT décodé. Il ressemble à l’extrait de code 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 JWT.
Une connexion locale et sociale combinée
Dans cet article, nos étapes d’orchestration de 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 à l’aide d’un compte local ou d’un compte social. Pour ce faire, de la première étape d’orchestration, l’élément ClaimsProviderSelections répertorie les options de connexion disponibles pour l’utilisateur.
Pour ajouter un compte local et social combiné, procédez comme suit :
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" />Veillez également à ajouter la
authenticationSourcerevendication dans la collection de revendications de sortie duUserSignInCollectorprofil technique autodéclaré.Dans la
UserJourneyssection, 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éé,
LocalAndSocialSignInAndSignUpajoutez 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>-->Dans la première étape, nous spécifions les options dont un utilisateur doit choisir dans son parcours, l’authentification locale ou sociale. Dans les étapes qui suivent, nous utilisons des conditions préalables pour suivre l’option choisie par l’utilisateur ou l’étape du parcours auquel l’utilisateur est. Par exemple, nous utilisons la
authenticationSourcerevendication pour différencier un parcours d’authentification local et un parcours d’authentification sociale.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 à l’aide d’un compte local ou d’un compte social.