Créer et lire un compte d’utilisateur à l’aide de la stratégie Azure Active Directory B2C personnalisée

Article
01/11/2024

Azure Active Directory B2C (Azure AD B2C) est construit sur Microsoft Entra ID et utilise donc le stockage Microsoft Entra ID pour stocker les comptes d'utilisateurs. Le profil utilisateur d’annuaire Azure AD B2C est fourni avec un ensemble intégré d’attributs, tels que le prénom, le nom de famille, la ville, le code postal et le numéro de téléphone, mais vous pouvez étendre le profil utilisateur avec vos propres attributs personnalisés sans demander de magasin de données externe.

Votre stratégie personnalisée peut se connecter au stockage Microsoft Entra ID à l'aide du profil technique Microsoft Entra ID pour stocker, mettre à jour ou supprimer les informations utilisateur. Dans cet article, vous apprenez comment configurer un ensemble de profils techniques Microsoft Entra ID pour stocker et lire un compte utilisateur avant qu'un jeton JWT ne soit renvoyé.

Présentation du scénario

Dans l'article Appeler une API REST à l'aide d'une stratégie personnalisée Azure Active Directory B2C, nous collectons des informations auprès de l'utilisateur, validons les données, appelons une API REST et retournons finalement un jeton JWT sans stocker de compte utilisateur. Nous devons stocker les informations utilisateur afin de ne pas les perdre une fois l’exécution de la stratégie terminée. Cette fois, lorsque nous avons collecté puis validé les informations utilisateur, nous devons les stocker dans le stockage Azure AD B2C, puis lire avant de retourner le jeton JWT. Le processus entier est présenté dans le diagramme suivant.

A flowchart of creating a user account in Azure AD.

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 Appeler une API REST à l’aide de la stratégie personnalisée Azure Active Directory B2C. 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 : Déclarer des revendications

Vous devez déclarer deux revendications supplémentaires, userPrincipalNameet passwordPolicies :

Dans le fichier ContosoCustomPolicy.XML, recherchez l’élément ClaimsSchema et déclarez les revendications userPrincipalName et passwordPolicies à l’aide du code suivant :

    <ClaimType Id="userPrincipalName">
        <DisplayName>UserPrincipalName</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Your user name as stored in the Azure Active Directory.</UserHelpText>
    </ClaimType>
    <ClaimType Id="passwordPolicies">
        <DisplayName>Password Policies</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Password policies used by Azure AD to determine password strength, expiry etc.</UserHelpText>
    </ClaimType>

En savoir plus sur les utilisations des revendications userPrincipalName et passwordPolicies dans l’article Attributs de profil utilisateur.

Étape 2 – Créer des profils techniques Microsoft Entra ID

Vous devez configurer deux profils techniques Microsoft Entra ID. Un profil technique écrit les détails de l'utilisateur dans le stockage Microsoft Entra ID et l'autre lit un compte utilisateur à partir du stockage Microsoft Entra ID.

Dans le fichier ContosoCustomPolicy.XML, recherchez l’élément ClaimsProviders et ajoutez un nouveau fournisseur de revendications à l’aide du code ci-dessous. Ce fournisseur de revendications détient les profils techniques Microsoft Entra ID :
```
    <ClaimsProvider>
        <DisplayName>Azure AD Technical Profiles</DisplayName>
        <TechnicalProfiles>
            
        </TechnicalProfiles>
    </ClaimsProvider>
```

dans le fournisseur de revendications que vous venez de créer, ajoutez un profil technique Microsoft Entra ID à l'aide du code suivant :

    <TechnicalProfile Id="AAD-UserWrite">
        <DisplayName>Write user information to AAD</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>
            <Item Key="UserMessageIfClaimsPrincipalAlreadyExists">The account already exists. Try to create another account</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <PersistedClaims>
            <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />        
            <PersistedClaim ClaimTypeReferenceId="displayName" />
            <PersistedClaim ClaimTypeReferenceId="givenName" />
            <PersistedClaim ClaimTypeReferenceId="surname" />
            <PersistedClaim ClaimTypeReferenceId="password"/>
            <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration,DisableStrongPassword" />
        </PersistedClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
        </OutputClaims>
    </TechnicalProfile>

nous avons ajouté un nouveau profil technique Microsoft Entra ID, AAD-UserWrite. Vous devez prendre note des parties importantes suivantes du profil technique :

Opération : l’opération spécifie l’action à effectuer, dans ce cas, Écrire. En savoir plus sur les autres opérations chez un fournisseur technique Microsoft Entra ID.
Revendications persistantes : l'élément PersistedClaims contient toutes les valeurs qui doivent être sauvegardées dans le stockage Microsoft Entra ID.
Revendications d’entrée : l’élément InputClaims contient une revendication utilisée pour rechercher un compte dans l’annuaire, ou pour en créer un. Il doit y avoir exactement un élément de revendication d'entrée dans la collection de revendications d'entrée pour tous les profils techniques Microsoft Entra ID. Ce profil technique utilise la revendication e-mail comme identificateur de clé pour le compte d’utilisateur. En savoir plus sur les autres identificateurs de clé que vous pouvez utiliser pour identifier un compte d’utilisateur de manière unique.

Dans le fichier ContosoCustomPolicy.XML, recherchez le profil technique AAD-UserWrite et ajoutez un nouveau profil technique déclaré automatiquement après celui-ci à l’aide du code suivant :

    <TechnicalProfile Id="AAD-UserRead">
        <DisplayName>Read user from Azure AD storage</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="RaiseErrorIfClaimsPrincipalAlreadyExists">false</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="givenName"/>
            <OutputClaim ClaimTypeReferenceId="surname"/>
            <OutputClaim ClaimTypeReferenceId="displayName"/>
        </OutputClaims>
    </TechnicalProfile>

Nous avons ajouté un nouveau profil technique Microsoft Entra ID, AAD-UserRead. Nous avons configuré ce profil technique pour qu’il effectue une opération de lecture et retourne les revendications objectId, userPrincipalName, givenName, surname et displayName si un compte d’utilisateur avec le email dans la section InputClaim est trouvé.

Étape 3 – Vous utilisez le profil technique Microsoft Entra ID

Après avoir collecté les détails de l'utilisateur à l'aide du profil technique auto-affirmé UserInformationCollector, nous devons écrire un compte utilisateur dans le stockage Microsoft Entra ID à l'aide du profil technique AAD-UserWrite. Pour ce faire, utilisez le profil technique AAD-UserWrite comme profil technique de validation dans le profil technique autodéclaré UserInformationCollector.

Dans le fichier ContosoCustomPolicy.XML, recherchez le profil technique UserInformationCollector, puis ajoutez le profil technique AAD-UserWrite en tant que profil technique de validation dans la collection ValidationTechnicalProfiles. Vous devez l’ajouter après le profil technique de validation CheckCompanyDomain.

Nous allons utiliser le profil technique AAD-UserRead dans les étapes d’orchestration du parcours utilisateur pour lire les détails de l’utilisateur avant d’émettre un jeton JWT.

Étape 4 : Mettre à jour le profil technique ClaimGenerator

Nous utilisons le profil technique ClaimGenerator pour exécuter trois transformations de revendications, GenerateRandomObjectIdTransformation, CreateDisplayNameTransformation et CreateMessageTransformation.

Dans le fichier ContosoCustomPolicy.XML, recherchez le profil technique ClaimGenerator et remplacez-le par le code suivant :

    <TechnicalProfile Id="UserInputMessageClaimGenerator">
        <DisplayName>User Message Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="message" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateMessageTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

    <TechnicalProfile Id="UserInputDisplayNameGenerator">
        <DisplayName>Display Name Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateDisplayNameTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

Nous avons divisé le profil technique en deux profils techniques distincts. Le profil technique UserInputMessageClaimGenerator génère le message envoyé en tant que revendication dans le jeton JWT. Le profil technique UserInputDisplayNameGenerator génère la revendication displayName. La valeur de la revendication displayName doit être disponible avant que le profil technique AAD-UserWrite n'écrive l'enregistrement utilisateur dans le stockage Microsoft Entra ID. Dans le nouveau code, nous supprimons GenerateRandomObjectIdTransformation au fur objectId et à mesure qu'il est créé et renvoyé par Microsoft Entra ID après la création d'un compte, nous n'avons donc pas besoin de le générer nous-mêmes dans la stratégie.

Dans le fichier ContosoCustomPolicy.XML, recherchez le profil technique autodéclaré UserInformationCollector, puis ajoutez le profil technique UserInputDisplayNameGenerator en tant que profil technique de validation. Après cela, la collection ValidationTechnicalProfiles du profil technique UserInformationCollector doit ressembler au code suivant :

    <!--<TechnicalProfile Id="UserInformationCollector">-->
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="CheckCompanyDomain">
                <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                        <Value>accountType</Value>
                        <Value>work</Value>
                        <Action>SkipThisValidationTechnicalProfile</Action>
                    </Precondition>
                </Preconditions>
            </ValidationTechnicalProfile>                        
            <ValidationTechnicalProfile ReferenceId="DisplayNameClaimGenerator"/>
            <ValidationTechnicalProfile ReferenceId="AAD-UserWrite"/>
        </ValidationTechnicalProfiles>
    <!--</TechnicalProfile>-->

Vous devez ajouter le profil technique de validation au préalable AAD-UserWrite, car la valeur de la réclamation displayName doit être disponible avant que le profil technique AAD-UserWrite n'écrive l'enregistrement utilisateur dans le stockage Microsoft Entra ID.

Étape 5 : Mettre à jour les étapes d’orchestration du parcours utilisateur

Localisez votre parcours utilisateur HelloWorldJourney et remplacer toutes les étapes d’orchestration par le code suivant :

    <!--<OrchestrationSteps>-->
        <OrchestrationStep Order="1" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
            </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetUserInformationClaimsExchange" TechnicalProfileReferenceId="UserInformationCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

À l’étape d’orchestration 4, nous exécutons le profil technique AAD-UserRead pour lire les détails de l’utilisateur (à inclure dans le jeton JWT) à partir du compte d’utilisateur créé.

Étant donné que nous ne stockons pas la revendication message, à l’étape d’orchestration 5, nous exécutons UserInputMessageClaimGenerator pour qu’il génère la revendication message à inclure sur le jeton JWT.

É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.

Une fois l’exécution de la stratégie terminée et que vous recevez votre jeton d’ID, vérifiez que l’enregistrement utilisateur a été créé :

Connectez-vous au portail Azure avec des autorisations d’administrateur général ou d’administrateur de rôle privilégié.
Si vous avez accès à plusieurs tenants, utilisez l’icône Paramètres dans le menu supérieur pour basculer vers votre tenant Azure AD B2C à partir du menu Répertoires + abonnements.
Sous Services Azure, sélectionnez Azure AD B2C. Vous pouvez également utiliser la zone de recherche pour rechercher et sélectionner Azure AD B2C.
Sous Gérer, sélectionnez Utilisateurs.
Recherchez le compte d’utilisateur que vous venez de créer, puis sélectionnez-le. Le profil de compte ressemble à la capture d’écran ci-dessous :

Dans notre profil technique Microsoft Entra ID AAD-UserWrite, nous précisons que si l'utilisateur existe déjà, nous générons un message d'erreur.

Testez à nouveau votre stratégie personnalisée en utilisant la même adresse e-mail. Au lieu que la stratégie s’exécute jusqu’à la fin pour émettre un jeton d’ID, vous devriez voir un message d’erreur similaire à la capture d’écran ci-dessous.

A screenshot of error as account already exists.

Remarque

La valeur de revendication mot de passe étant une information très importante, soyez très prudent dans la façon dont vous la gérez dans votre stratégie personnalisée. Pour une raison similaire, Azure AD B2C traite la valeur de revendication de mot de passe comme une valeur spéciale. Lorsque vous collectez la valeur de revendication de mot de passe dans le profil technique autodéclaré, cette valeur n’est disponible que dans le même profil technique ou dans un profil technique de validation référencé par ce même profil technique autodéclaré. Une fois l’exécution de ce profil technique autodéclaré terminée et déplacée vers un autre profil technique, la valeur est perdue.

Vérifiez l’adresse e-mail de l’utilisateur

Nous vous recommandons de vérifier l’e-mail d’un utilisateur avant de l’utiliser pour créer un compte d’utilisateur. Lorsque vous vérifiez les adresses e-mail, vous vous assurez que les comptes sont créés par des utilisateurs réels. Vous aidez aussi les utilisateurs à s’assurer qu’ils utilisent leur adresse e-mail correcte pour créer un compte.

La stratégie personnalisée d’Azure AD B2C permet de vérifier l’adresse e-mail à l’aide du contrôle d’affichage de vérification. Vous envoyez un code de vérification à l’e-mail. Après l’envoi du code, l’utilisateur lit le message, saisit le code de vérification dans le contrôle fourni par le contrôle d’affichage, puis sélectionne le bouton Vérifier le code.

Un contrôle d’affichage est un élément d’interface utilisateur qui présente une fonctionnalité particulière et interagit avec le service principal Azure Active Directory B2C (Azure AD B2C). Il permet à l’utilisateur d’exécuter des actions sur la page qui appellent un profil technique de validation dans le back end. Les contrôles d’affichage sont affichés sur la page et sont référencés par un profil technique auto-déclaré.

Pour ajouter la vérification par e-mail à l’aide d’un contrôle d’affichage, procédez ainsi :

Déclarez une revendication

Vous devez déclarer une revendication à utiliser pour contenir le code de vérification.

Pour déclarer la revendication, dans le fichier ContosoCustomPolicy.XML, recherchez l’élément ClaimsSchema et déclarez la revendication verificationCode à l’aide du code suivant :

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="verificationCode">
            <DisplayName>Verification Code</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Enter your verification code</UserHelpText>
            <UserInputType>TextBox</UserInputType>
        </ClaimType>
    <!--</ClaimsSchema>-->

Configurer un profil technique d’envoi et de vérification du code

Azure AD B2C utilise le profil technique Microsoft Entra ID SSPR pour vérifier une adresse e-mail. Ce profil technique peut générer et envoyer un code à une adresse e-mail ou vérifier le code en fonction de la façon dont vous le configurez.

Dans le fichier ContosoCustomPolicy.XML, recherchez l’élément ClaimsProviders et ajoutez le fournisseur de revendications à l’aide du code suivant :

    <ClaimsProvider>
        <DisplayName>Azure AD self-service password reset (SSPR)</DisplayName>
        <TechnicalProfiles>
            <TechnicalProfile Id="AadSspr-SendCode">
            <DisplayName>Send Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">SendCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
            <TechnicalProfile Id="AadSspr-VerifyCode">
            <DisplayName>Verify Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">VerifyCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="verificationCode" />
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
        </TechnicalProfiles>
    </ClaimsProvider>

Nous avons configuré deux profils techniques, AadSspr-SendCode et AadSspr-VerifyCode. AadSspr-SendCode génère et envoie un code à l’adresse e-mail spécifiée dans la section InputClaims, tandis que AadSspr-VerifyCode vérifie le code. Vous spécifiez l’action que vous souhaitez effectuer dans les métadonnées du profil technique.

Configurer un contrôle d’affichage

Vous devez configurer un contrôle d’affichage de vérification de l’e-mail pour pouvoir vérifier les e-mails des utilisateurs. Le contrôle d’affichage de vérification des e-mails que vous configurez remplace la revendication d’affichage des e-mails que vous utilisez pour collecter un e-mail auprès de l’utilisateur.

Pour configurer un contrôle d’affichage, procédez ainsi :

Dans le fichier ContosoCustomPolicy.XML, recherchez la section BuildingBlocks, puis ajoutez un contrôle d’affichage en tant qu’élément enfant à l’aide du code suivant :

    <!--<BuildingBlocks>-->
        ....
        <DisplayControls>
            <DisplayControl Id="emailVerificationControl" UserInterfaceControlType="VerificationControl">
              <DisplayClaims>
                <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
                <DisplayClaim ClaimTypeReferenceId="verificationCode" ControlClaimType="VerificationCode" Required="true" />
              </DisplayClaims>
              <OutputClaims></OutputClaims>
              <Actions>
                <Action Id="SendCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-SendCode" />
                  </ValidationClaimsExchange>
                </Action>
                <Action Id="VerifyCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-VerifyCode" />
                  </ValidationClaimsExchange>
                </Action>
              </Actions>
            </DisplayControl>
        </DisplayControls> 
    <!--</BuildingBlocks>-->

Nous avons déclaré un contrôle d’affichage, emailVerificationControl. Notez bien les points importants suivants :

DisplayClaims : tout comme dans un profil technique autodéclaré, cette section spécifie une collection de revendications à collecter auprès de l’utilisateur dans le contrôle d’affichage.
Actions : spécifie l’ordre des actions à effectuer par le contrôle d’affichage. Chaque action fait référence à un profil technique responsable de l’exécution des actions. Par exemple, SendCode référence le profil technique AadSspr-SendCode, qui génère et envoie un code à une adresse e-mail.

Dans le fichier ContosoCustomPolicy.XML, recherchez le profil technique autodéclaré UserInformationCollector et remplacez la revendication d’affichage de l’e-mail pour le contrôle d’affichage emailVerificationControl :

De :
```
    <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>
```
Par :
```
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
```
Utilisez la procédure décrite à l’étape 6 et à l’étape 7 pour charger votre fichier de stratégie et le tester. Cette fois, vous devez vérifier votre adresse e-mail avant de créer un compte d’utilisateur.

Mettre à jour le compte utilisateur à l'aide du profil technique Microsoft Entra ID

Vous pouvez configurer un profil technique Microsoft Entra ID pour mettre à jour un compte utilisateur au lieu d'essayer d'en créer un nouveau. Pour ce faire, définissez le profil technique Microsoft Entra ID pour qu'il génère une erreur si le compte utilisateur spécifié n'existe pas déjà dans la collection Metadata à l'aide du code suivant. L’opération doit être définie sur Écrire :

    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>

Utilisation d’attributs personnalisés

Dans cet article, vous avez appris à stocker les détails de l’utilisateur à l’aide d’attributs de profil utilisateur intégrés. Toutefois, vous devez souvent créer vos propres attributs pour gérer votre scénario spécifique. Pour ce faire, suivez les instructions de l’article Définir des attributs personnalisés dans Azure Active Directory B2C.

Étapes suivantes

Apprenez à configurer un flux d’inscription et de connexion pour un compte local en utilisant une stratégie Azure Active Directory B2C personnalisée.
Découvrez comment définir des attributs personnalisés dans votre stratégie personnalisée.
Découvrez comment ajouter une expiration du mot de passe à une stratégie personnalisée.
En savoir plus sur le profil technique Microsoft Entra ID.

Partager via