Dela via

Konceptbevis för det globala identitetsramverket i Azure Active Directory B2C för regionbaserad konfiguration

  • Artikel

I följande avsnitt beskrivs hur du skapar konceptbevisimplementeringar för regionbaserad orkestrering. Du hittar de färdiga anpassade principerna för Azure Active Directory B2C (Azure AD B2C) här.

Regionbaserad metod

Varje regional Azure AD B2C-klientorganisation kräver en Azure AD anpassad B2C-princip som innehåller följande funktioner:

Registreringsresa:

  • Visa en skärm för att samla in användarens användarnamn, lösenord och andra attribut
  • Förhindra registrering om användaren redan finns genom att fråga mappningstabellen för användarområden
  • Skriva användarprofilen till den lokala klientorganisationen
  • Skriva användarens mappning mellan användarnamn och region till en mappningstabell
  • Utfärda en token till programmet

Inloggningsresa:

  • Skärmen Visa användarnamn och lösenord
  • Utför en sökning av användarnamnet och returnera dess region
  • Utföra en lokal verifiering av autentiseringsuppgifter eller en verifiering av autentiseringsuppgifter mellan klientorganisationer
  • Läsa användarprofilen från den lokala klientorganisationen eller via ett anrop mellan klientorganisationer
  • Utfärda en token till programmet

Resa för lösenordsåterställning:

  • Visa en skärm för att verifiera användarnas e-post via e-post OTP
  • Utför en sökning av användarnamnet och returnera dess region
  • Visa en skärm för att samla in det nya lösenordet
  • Skriv det nya lösenordet till den lokala klientorganisationen eller via ett anrop mellan klientorganisationer
  • Utfärda en token till programmet

Följande blockdiagram visar konceptbeviset. Vägledningen visar hur du konfigurerar Azure AD B2C-klientorganisationer. Det externa API-lagret och den geo-distribuerade uppslagstabellen ingår inte som en del av den här guiden.

Skärmbild som visar det regionalbaserade metodblockeringsdiagrammet

Förutsättningar

  1. Skapa en klientorganisation per region som företaget behöver stöd för. Du behöver minst två klientorganisationer för det här konceptbeviset.

  2. Distribuera anpassade principer till dina klienter.

Förbereda lagringsskiktet

Du behöver ett lagringslager som kan lagra användarnas e-post, objectId och region. På så sätt kan du spåra och fråga var användaren registrerade sig. Du kan använda en Azure Storage-tabell för att spara dessa data.

Förbereda DITT API-lager

Det finns flera API:er som används som en del av konceptbeviset för att demonstrera den regionbaserade metoden.

Kontrollera om användaren redan finns

Ett API används under registreringen för att avgöra om användaren redan finns i någon region.

Begäran kommer att vara följande:

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

{
  email: bob@contoso.com
}

  • Svaret ska vara http 200 om användaren inte finns.

  • Svaret ska vara HTTP 409 om användaren finns.

Registrera mappning av användarregion

Ett API används under registreringen för att registrera vilken region användaren har registrerat sig i.

Begäran kommer att vara följande:

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

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

  • Svaret ska vara http 200 om användaren finns.

  • Svaret ska vara HTTP 409 om användaren finns.

Returnera vilken region användaren finns i

Ett API används under inloggningen för att avgöra i vilken region användaren har registrerat sig. Detta anger om en autentisering mellan klientorganisationer krävs för att utföras.

Begäran kommer att vara följande:

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

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

Svaret ska vara en HTTP 200 med den användarregistrerade regionen och objectId.

{
  "objectId": "460f9ffb-8b6b-458d-a5a4-b8f3a6816fc2",
  "region": "APAC"  
}

API:et bör svara med en HTTP 409 om användaren inte finns eller påträffar ett fel.

Skriva lösenord mellan klientorganisationer

Ett API används under flödet för lösenordsåterställning för att skriva användarnas nya lösenord i en annan region som de återställer sitt lösenord på.

Begäran kommer att vara följande:

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

{
  "objectId": "460f9ffb-8b6b-458d-a5a4-b8f3a6816fc2",
  "password": "some!strong123STRING"
}

Svaret ska vara en HTTP 200 om processen lyckas, eller HTTP 409 om det finns ett fel.

Regionbaserad Azure AD B2C-konfiguration

Följande avsnitt förbereder Azure AD B2C-klientorganisation för att spåra den region där användaren registrerade sig och utföra autentiseringar mellan klientorganisationer eller lösenordsåterställning om det behövs.

Registrera anpassad principkonfiguration

Under registreringen måste vi kontrollera att användaren inte finns i någon annan klientorganisation och skriva mappningen för användarens användarregion till en extern tabell.

Ändra den LocalAccountSignUpWithLogonEmail tekniska profilen i Azure AD B2C-startpaketet är följande:

<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 utför följande logik:

  1. Hämta en token för att anropa dina skyddade API-slutpunkter med hjälp av den REST-getTokenforExternalApiCalls tekniska profilen.

    • Följ dokumentationen här för att hämta och skydda ditt API med hjälp av en Microsoft Entra ägartoken.

  2. Kontrollera om användaren redan finns i mappningen mellan användare och region via din skyddade externa REST API-slutpunkt:

    • Det här API-anropet görs innan alla registreringar. Det är viktigt att se till att det här API:et har rätt mekanismer för belastningsutjämning, återhämtning och redundans för att upprätthålla drifttidskraven.

    • Ett exempel på en teknisk profil för att fråga en mappning mellan användare och region via ett externt REST-API är följande:

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

    • Det här API:et bör svara med HTTP 409 om användaren finns, med lämpligt felmeddelande som ska visas på skärmen. Annars svarar du med en HTTP 200 om användaren inte finns.

  3. Skriva mappningen mellan användare och region via din skyddade externa REST API-slutpunkt

    • Det här API-anropet görs innan alla registreringar. Det är viktigt att se till att det här API:et har rätt mekanismer för belastningsutjämning, återhämtning och redundans för att upprätthålla drifttidskraven.

    • Ett exempel på en teknisk profil för att skriva mappningen mellan användare och region via ett externt REST-API är följande:

    <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>
``` 

Logga in med anpassad principkonfiguration

Under inloggningen måste vi fastställa användarens profilplats och autentisera dem mot den Azure AD B2C-klientorganisation där deras profil finns.

Ändra den SelfAsserted-LocalAccountSignin-Email tekniska profilen i Azure AD B2C-startpaketet för att utföra sökningen i användarregionen och utföra autentisering mellan klientorganisationer när användaren är från en annan region än den klientorganisation som användaren har nått. Uppdatera som ValidationTechnicalProfiles :

<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 utför följande logik när användaren skickar sina autentiseringsuppgifter:

  1. Hämta en token för att anropa dina skyddade API-slutpunkter med hjälp av den REST-getTokenforExternalApiCalls tekniska profilen.

    • Följ dokumentationen här för att hämta och skydda ditt API med hjälp av en Microsoft Entra ägartoken.

  2. Leta upp mappningen mellan användare och region via din skyddade externa REST API-slutpunkt

    • Det här API-anropet görs innan alla registreringar. Det är viktigt att se till att det här API:et har rätt mekanismer för belastningsutjämning, återhämtning och redundans för att upprätthålla drifttidskraven.

    • Ett exempel på en teknisk profil för att fråga en mappning mellan användare och region via ett externt REST-API är följande:

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

  3. Utför lokal kontoautentisering via den login-NonInteractive tekniska profilen för användare som har registrerat sig i den här klientorganisationen. Det här är den tekniska standardprofil som finns i Azure AD B2C-startpaketet.

  4. Villkorligt utför du en autentisering mellan klientorganisationer via de REST-login-NonInteractive-[region] tekniska profilerna för varje respektive region.

    • Detta hämtar också en MS-Graph API-token från användarens hemklientorganisation. Registrera en registrering av inbyggda program i varje regional klientorganisation med behörighet till MS Graph API för den delegerade behörigheten user.read.

    • Ett exempel på en teknisk profil för att utföra mappning mellan användare och region via ett externt REST-API är följande:

      <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="cf3f6898-9a79-426a-ba16-10e1a377c843" />
    <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>

    • Ersätt <yourb2ctenant> i ServiceUrl med den klientorganisation som du behöver ange som mål för autentisering.

    • Använd programregistreringen ApplicationId för att fylla i DefaultValue för det inkommande anspråket apac_client_id .

  5. Villkorligt hämtar du användarprofilen med hjälp av ett REST API-anrop mellan klientorganisationer via de REST-fetchUserProfile-[region] tekniska profilerna för varje respektive region.

    • Ett exempel på en teknisk profil för att läsa användarens profil via MS Graph API är följande:

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

Konfiguration av anpassad princip för lösenordsåterställning

Under lösenordsåterställningen måste vi fastställa användarens profilplats och uppdatera lösenordet mot den Azure AD B2C-klientorganisation där användarprofilen finns.

Ändra den LocalAccountSignUpWithLogonEmail tekniska profilen i Azure AD B2C-startpaketet för att utföra sökningen i användarregionen och uppdatera lösenordet i respektive klientorganisation. Uppdatera som ValidationTechnicalProfiles :

<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 utför följande logik när användaren skickar ett verifierat e-postmeddelande för att uppdatera sitt lösenord:

  1. Hämta en token för att anropa dina skyddade API-slutpunkter

  2. Leta upp mappningen mellan användare och region via din skyddade externa REST API-slutpunkt

    • Det här API-anropet görs innan alla försök till lösenordsåterställning görs. Det är viktigt att se till att det här API:et har rätt mekanismer för belastningsutjämning, återhämtning och redundans för att upprätthålla drifttidskraven.

Ändra den LocalAccountWritePasswordUsingObjectId tekniska profilen för att skriva det nya lösenordet till den lokala klientorganisationen eller villkorligt till den tvärregionala klientorganisationen.

<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 utför följande logik när användaren skickar ett nytt lösenord:

  1. Skriv användarnas nya lösenord till katalogen om användaren fanns i EMEA-klientorganisationen (den här klientorganisationen).

  2. Skriv villkorligt det nya lösenordet till användarprofilen i den region där användarprofilen finns med hjälp av ett REST API-anrop.

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

Nästa steg