Preuve de concept du framework d’identité globale Azure Active Directory B2C pour la configuration basée sur la région

Article
01/24/2024

La section suivante explique comment créer des implémentations de preuve de concept pour l’orchestration basée sur la région. Les stratégies personnalisées Azure Active Directory B2C (Azure AD B2C) terminées sont disponibles ici.

Approche basée sur la région

Chaque client Azure AD B2C régional nécessite une stratégie personnalisée Azure AD B2C, qui contient les fonctionnalités suivantes :

Parcours d’inscription :

Afficher un écran pour recueillir le nom d’utilisateur, le mot de passe et tout autre attribut de l’utilisateur
Empêcher l’inscription si l’utilisateur existe déjà en interrogeant le tableau de mappage utilisateur-région
Écrire le profil utilisateur dans le locataire local
Écrire le mappage de nom d’utilisateur à région des utilisateurs dans un tableau de mappage
Émettre un jeton pour l’application

Parcours de connexion :

Afficher l’écran de nom d’utilisateur et mot de passe
Effectuer une recherche du nom d’utilisateur et renvoyer sa région
Effectuer une vérification des informations d’identification locales ou une vérification des informations d’identification entre locataires
Lire le profil utilisateur à partir du locataire local ou via un appel entre locataires
Émettre un jeton pour l’application

Parcours de réinitialisation du mot de passe :

Afficher un écran pour valider l’e-mail des utilisateurs via un e-mail à usage unique
Effectuer une recherche du nom d’utilisateur et renvoyer sa région
Afficher un écran pour capturer le nouveau mot de passe
Écrire le nouveau mot de passe au locataire local ou via un appel entre locataires
Émettre un jeton pour l’application

Le diagramme de blocs suivant montre la preuve de concept. Les instructions montrent comment configurer les locataires Azure AD B2C. La couche d’API externe et le tableau de recherche géo-distribuée ne sont pas incluses dans ce guide.

Capture d’écran montrant le diagramme de blocs d’approche régionale.

Prérequis

Créez un locataire par région dont votre entreprise a besoin pour la prise en charge. Vous aurez besoin d’au moins deux locataires pour cette preuve de concept.
Déployer des stratégies personnalisées dans vos locataires.

Préparer votre couche de stockage

Vous aurez besoin d’une couche de stockage, qui peut stocker l’e-mail, l’objectId et la région des utilisateurs. Elle vous permettra de suivre et d’interroger l’emplacement où l’utilisateur s’est inscrit. Vous pouvez utiliser un tableau Stockage Azure pour conserver ces données.

Préparer votre couche API

Plusieurs API sont utilisées dans le cadre de la preuve de concept pour illustrer l’approche régionale.

Vérifier si l’utilisateur existe déjà ou non

Une API est utilisée lors de l’inscription pour déterminer si l’utilisateur existe déjà dans une région ou non.

La demande se présente comme suit :

POST /doesUserExistInLookupTable HTTP/1.1
Host: yourapi.com
Content-Type: application/json

{
  email: bob@contoso.com
}

La réponse doit être HTTP 200 si l’utilisateur n’existe pas.
La réponse doit être HTTP 409 si l’utilisateur existe déjà.

Enregistrer le mappage de région des utilisateurs

Une API est utilisée lors de l’inscription pour enregistrer la région dans laquelle l’utilisateur s’est inscrit.

La demande se présente comme suit :

POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "email": "bob@contoso.com"
}

La réponse doit être HTTP 200 si l’utilisateur existe.
La réponse doit être HTTP 409 si l’utilisateur existe déjà.

Renvoyer la région dans laquelle l’utilisateur existe

Une API est utilisée lors de la connexion pour déterminer dans quelle région l’utilisateur s’est inscrit. Cela indique si une authentification entre locataires doit être effectuée.

La demande se présente comme suit :

POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "email": "bob@contoso.com"
}

La réponse doit être un HTTP 200 avec la région et l’objectId inscrits par les utilisateurs.

{
  "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "region": "APAC"  
}

L’API doit répondre avec un HTTP 409 si l’utilisateur n’existe pas ou rencontre une erreur.

Écrire un mot de passe entre les locataires

Une API est utilisée pendant le flux de réinitialisation de mot de passe pour écrire le nouveau mot de passe des utilisateurs dans une autre région où ils réinitialisent leur mot de passe.

La demande se présente comme suit :

POST /writePasswordCrossTenant HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json

{
  "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "password": "some!strong123STRING"
}

La réponse doit être HTTP 200 si le processus réussit, ou HTTP 409 en cas d’erreur.

Configuration régionale Azure AD B2C

Les sections suivantes préparent le locataire Azure AD B2C à suivre la région dans laquelle l’utilisateur s’est inscrit et effectuer des authentifications entre locataires ou des réinitialisations de mot de passe si nécessaire.

Pendant l’inscription, nous devons nous assurer que l’utilisateur n’existe pas dans un autre locataire et écrire le mappage utilisateur-région des utilisateurs dans une table externe.

Modifier le profil technique LocalAccountSignUpWithLogonEmail dans le pack de démarrage Azure AD B2C comme suit :

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
...
  <ValidationTechnicalProfiles>            
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls" />
    <ValidationTechnicalProfile ReferenceId="REST-doesUserExistInLookupTable" />        
    <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
    <ValidationTechnicalProfile ReferenceId="REST-writeUserToRegionMapping" />
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

ValidationTechnicalProfiles exécutera la logique suivante :

Obtenir un jeton pour appeler vos points de terminaison d’API protégés à l’aide du profil technique REST-getTokenforExternalApiCalls.
- Suivez la documentation ici pour obtenir et protéger votre API à l’aide d’un jeton du porteur Microsoft Entra.

Vérifier si l’utilisateur existe déjà dans le mappage utilisateur-région via votre point de terminaison d’API REST externe sécurisé :

Cet appel d’API est effectué avant toutes les inscriptions. Il est essentiel de s’assurer que cette API dispose de mécanismes d’équilibrage de charge, de résilience et de basculement appropriés pour respecter les exigences de temps de fonctionnement.

Voici un exemple de profil technique permettant d’interroger un mappage utilisateur-région via une API REST externe comme suit :

<TechnicalProfile Id="REST-doesUserExistInLookupTable ">
<DisplayName>User to Region lookup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
  <Item Key="ServiceUrl">https://myApi.com/doesUserExistInLookupTable</Item>
  <Item Key="AuthenticationType">Bearer</Item>
  <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
  <Item Key="SendClaimsIn">Body</Item>
  <Item Key="AllowInsecureAuthInProduction">false</Item>
</Metadata>
<InputClaims>
  <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Cette API doit répondre avec HTTP 409 si l’utilisateur existe, avec le message d’erreur approprié à afficher à l’écran. Sinon, répondez avec un HTTP 200 si l’utilisateur n’existe pas.

Écrire le mappage utilisateur-région via votre point de terminaison d’API REST externe sécurisé

Cet appel d’API est effectué avant toutes les inscriptions. Il est essentiel de s’assurer que cette API dispose de mécanismes d’équilibrage de charge, de résilience et de basculement appropriés pour respecter les exigences de temps de fonctionnement.
Voici un exemple de profil technique permettant d’écrire le mappage utilisateur-région via une API REST externe :

<TechnicalProfile Id="REST-writeUserToRegionMapping">
<DisplayName>User to Region lookup</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
  <Item Key="ServiceUrl">https://myApi.com/writeUserToRegionMapping</Item>
  <Item Key="AuthenticationType">Bearer</Item>
  <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
  <Item Key="SendClaimsIn">Body</Item>
  <Item Key="AllowInsecureAuthInProduction">false</Item>
</Metadata>
<InputClaims>
  <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
  <InputClaim ClaimTypeReferenceId="region" DefaultValue="EMEA" />
  <InputClaim ClaimTypeReferenceId="objectId" />
</InputClaims>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>
```

Lors de la connexion, nous devons déterminer l’emplacement du profil des utilisateurs et les authentifier auprès du locataire Azure AD B2C où réside leur profil.

Modifier le profil technique SelfAsserted-LocalAccountSignin-Email dans le pack de démarrage Azure AD B2C pour effectuer la recherche utilisateur-région et procéder à l’authentification entre locataires lorsque l’utilisateur est d’une autre région que celle du locataire qu’il a atteint. Mettre à jour le ValidationTechnicalProfiles en tant que :

<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
...
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls" />
    <ValidationTechnicalProfile ReferenceId="REST-regionLookup" />
    <ValidationTechnicalProfile ReferenceId="login-NonInteractive">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>EMEA</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
     <ValidationTechnicalProfile ReferenceId="REST-login-NonInteractive-APAC">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>APAC</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-fetchUserProfile-APAC">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>user_region</Value>
          <Value>APAC</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

ValidationTechnicalProfiles effectue la logique suivante lorsque l’utilisateur envoie ses informations d’identification :

Obtenir un jeton pour appeler vos points de terminaison d’API protégés à l’aide du profil technique REST-getTokenforExternalApiCalls.
- Suivez la documentation ici pour obtenir et protéger votre API à l’aide d’un jeton du porteur Microsoft Entra.

Rechercher le mappage utilisateur-région via votre point de terminaison d’API REST externe sécurisé

Cet appel d’API est effectué avant toutes les inscriptions. Il est essentiel de s’assurer que cette API dispose de mécanismes d’équilibrage de charge, de résilience et de basculement appropriés pour respecter les exigences de temps de fonctionnement.

Voici un exemple de profil technique permettant d’interroger un mappage utilisateur-région via une API REST externe comme suit :

<TechnicalProfile Id="REST-regionLookup">
  <DisplayName>User to Region lookup</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://myApi.com/userToRegionLookup</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
    <Item Key="AllowInsecureAuthInProduction">false</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="email" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="user_region" PartnerClaimType="region" />
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Effectuer l’authentification de compte local via le profil technique login-NonInteractive pour les utilisateurs qui se sont inscrits dans ce locataire. Il s’agit du profil technique par défaut trouvé dans le pack de démarrage Azure AD B2C.

De manière conditionnelle, effectuez une authentification entre locataires via les profils techniques REST-login-NonInteractive-[region] de chaque région respective.

Cela permet également d’obtenir un jeton MS API Graph auprès du locataire d’origine de l’utilisateur. Inscrire l’inscription d’application native dans chaque locataire régional avec des autorisations sur MS API Graph pour l’autorisation déléguée user.read.

Voici un exemple de profil technique permettant d’effectuer un mappage utilisateur-région via une API REST externe comme suit :

<TechnicalProfile Id="REST-login-NonInteractive-APAC">
  <DisplayName>non interactive authentication to APAC</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://login.microsoftonline.com/yourAPACb2ctenant.onmicrosoft.com/oauth2/v2.0/token</Item>
    <Item Key="AuthenticationType">None</Item>
    <Item Key="SendClaimsIn">Form</Item>
    <Item Key="AllowInsecureAuthInProduction">true</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="apac_client_id" PartnerClaimType="client_id" DefaultValue="00001111-aaaa-2222-bbbb-3333cccc4444" />
    <InputClaim ClaimTypeReferenceId="ropc_grant_type" PartnerClaimType="grant_type" DefaultValue="password" />
    <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="username" />
    <InputClaim ClaimTypeReferenceId="password" />
    <InputClaim ClaimTypeReferenceId="scope" DefaultValue="https://graph.microsoft.com/.default" AlwaysUseDefaultValue="true" />
    <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="ext_Api_bearerToken" PartnerClaimType="access_token" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Remplacez <yourb2ctenant> dans ServiceUrl par le locataire que vous devez cibler pour l’authentification.
Utilisez l’inscription de l’application ApplicationId pour remplir le DefaultValue pour la revendication d’entrée apac_client_id.

De manière conditionnelle, récupérez le profil utilisateur à l’aide d’un appel d’API REST entre locataires via les profils techniques REST-fetchUserProfile-[region] de chaque région respective.

Voici un exemple de profil technique permettant de lire le profil de l’utilisateur via MS API Graph comme suit :

<TechnicalProfile Id="REST-fetchUserProfile-APAC">
  <DisplayName>fetch user profile cross tenant</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://graph.microsoft.com/beta/me</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">graph_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="graph_bearerToken" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="id" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surName" />
    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
  </OutputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Configuration de stratégie personnalisée de réinitialisation de mot de passe

Lors de la réinitialisation du mot de passe, nous devons déterminer l’emplacement du profil des utilisateurs et mettre à jour le mot de passe par rapport au locataire Azure AD B2C où réside le profil utilisateur.

Modifier le profil technique LocalAccountSignUpWithLogonEmail dans le pack de démarrage Azure AD B2C pour effectuer la recherche utilisateur-région et mettre à jour le mot de passe dans le locataire respectif. Mettre à jour le ValidationTechnicalProfiles en tant que :

<TechnicalProfile Id="LocalAccountDiscoveryUsingEmailAddress">
  <OutputClaims>
  ...
  <OutputClaim ClaimTypeReferenceId="ext_Api_bearerToken" DefaultValue="EMEA"/>
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="REST-getTokenforExternalApiCalls">
      <Preconditions>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
          <Value>user_region</Value>
          <Value>EMEA</Value>
          <Action>SkipThisValidationTechnicalProfile</Action>
        </Precondition>
      </Preconditions>
    </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-regionLookup" />
    <ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingEmailAddress" />
  </ValidationTechnicalProfiles>
</TechnicalProfile>

ValidationTechnicalProfiles effectue la logique suivante lorsque l’utilisateur envoie un e-mail vérifié pour mettre à jour son mot de passe :

Obtenir un jeton pour appeler vos points de terminaison d’API protégés
Rechercher le mappage utilisateur-région via votre point de terminaison d’API REST externe sécurisé
- Cet appel d’API est effectué avant toutes les tentatives de réinitialisation de mot de passe. Il est essentiel de s’assurer que cette API dispose de mécanismes d’équilibrage de charge, de résilience et de basculement appropriés pour respecter les exigences de temps de fonctionnement.

Modifier le profil technique LocalAccountWritePasswordUsingObjectId pour écrire le nouveau mot de passe dans le locataire local ou de manière conditionnelle dans le locataire entre régions.

<TechnicalProfile Id="LocalAccountWritePasswordUsingObjectId">
  ...
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AAD-UserWritePasswordUsingObjectId">
        <Preconditions>
          <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
            <Value>user_region</Value>
            <Value>EMEA</Value>
            <Action>SkipThisValidationTechnicalProfile</Action>
          </Precondition>
        </Preconditions>
      </ValidationTechnicalProfile>
    <ValidationTechnicalProfile ReferenceId="REST-UserWritePasswordUsingObjectId-APAC">
        <Preconditions>
          <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
            <Value>user_region</Value>
            <Value>APAC</Value>
            <Action>SkipThisValidationTechnicalProfile</Action>
          </Precondition>
        </Preconditions>
      </ValidationTechnicalProfile>
  </ValidationTechnicalProfiles>
</TechnicalProfile>

ValidationTechnicalProfiles effectue la logique suivante lorsque l’utilisateur présente un nouveau mot de passe :

Écrire le nouveau mot de passe des utilisateurs dans l’annuaire si l’utilisateur existait dans le locataire EMEA (ce locataire).

De manière conditionnelle, écrivez le nouveau mot de passe dans le profil utilisateur dans la région où réside le profil utilisateur, à l’aide d’un appel d’API REST.

<TechnicalProfile Id="REST-UserWritePasswordUsingObjectId-APAC">
  <DisplayName>Write password to APAC tenant</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ServiceUrl">https://myApi.com/writePasswordCrossTenant</Item>
    <Item Key="AuthenticationType">Bearer</Item>
    <Item Key="UseClaimAsBearerToken">ext_Api_bearerToken</Item>
    <Item Key="SendClaimsIn">Body</Item>
    <Item Key="DebugMode">true</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="ext_Api_bearerToken" />
    <InputClaim ClaimTypeReferenceId="objectId" />
    <InputClaim ClaimTypeReferenceId="newPassword" />
  </InputClaims>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

Partager via

Preuve de concept du framework d’identité globale Azure Active Directory B2C pour la configuration basée sur la région

Approche basée sur la région

Prérequis

Préparer votre couche de stockage

Préparer votre couche API

Vérifier si l’utilisateur existe déjà ou non

Enregistrer le mappage de région des utilisateurs

Renvoyer la région dans laquelle l’utilisateur existe

Écrire un mot de passe entre les locataires

Configuration régionale Azure AD B2C

Configuration de stratégie personnalisée de réinitialisation de mot de passe

Étapes suivantes

Commentaires

Ressources supplémentaires

Partager via

Preuve de concept du framework d’identité globale Azure Active Directory B2C pour la configuration basée sur la région

Approche basée sur la région

Prérequis

Préparer votre couche de stockage

Préparer votre couche API

Vérifier si l’utilisateur existe déjà ou non

Enregistrer le mappage de région des utilisateurs

Renvoyer la région dans laquelle l’utilisateur existe

Écrire un mot de passe entre les locataires

Configuration régionale Azure AD B2C

S’inscrire à la configuration de stratégie personnalisée

Configuration de stratégie personnalisée de connexion

Configuration de stratégie personnalisée de réinitialisation de mot de passe

Étapes suivantes

Commentaires

Ressources supplémentaires