Подтверждение концепции платформы глобальных удостоверений Azure Active Directory B2C для конфигурации на основе региона
В следующем разделе описывается, как создать реализацию подтверждения концепции для оркестрации на основе регионов. Готовые настраиваемые политики Azure Active Directory B2C (Azure AD B2C) можно найти здесь.
Подход на основе регионов
Для каждого регионального клиента B2C Azure AD потребуется Azure AD настраиваемая политика B2C, которая содержит следующие возможности:
Путь регистрации:
- Отображение экрана для сбора имени пользователя, пароля и других атрибутов
- Запретите регистрацию, если пользователь уже существует, запросив таблицу сопоставления пользовательского региона.
- Запись профиля пользователя в локальный клиент
- Запись сопоставления имени пользователя с регионами в таблицу сопоставления
- Выдача маркера приложению
Путь входа:
- Отображение экрана имени пользователя и пароля
- Выполните поиск имени пользователя и верните его регион
- Проверка локальных или межтенантных учетных данных
- Чтение профиля пользователя из локального клиента или через межклиентный вызов
- Выдача маркера приложению
Путь сброса пароля:
- Отображение экрана для проверки электронной почты пользователей по электронной почте OTP
- Выполните поиск имени пользователя и верните его регион
- Отображение экрана для записи нового пароля
- Запишите новый пароль в локальный клиент или через вызов между клиентами.
- Выдача маркера приложению
На следующей блок-схеме показано подтверждение концепции. В этом руководстве показано, как настроить Azure AD клиентов B2C. Внешний уровень API и таблица распределенного географического поиска не включены в это руководство.
Предварительные требования
Создайте клиент для каждого региона, который требуется вашей организации для поддержки. Для этого подтверждения концепции вам потребуется по крайней мере два клиента.
Развертывание пользовательских политик в клиентах.
Подготовка уровня хранилища
Вам потребуется уровень хранилища, на котором могут храниться сообщения электронной почты пользователей, objectId и регион. Это позволит отслеживать и запрашивать место регистрации пользователя. Для сохранения этих данных можно использовать таблицу службы хранилища Azure .
Подготовка уровня API
Существует несколько API, используемых в рамках подтверждения концепции для демонстрации подхода на основе регионов.
Проверьте, существует ли пользователь.
API используется во время регистрации, чтобы определить, существует ли пользователь в любом регионе.
Запрос будет следующим:
POST /doesUserExistInLookupTable HTTP/1.1
Host: yourapi.com
Content-Type: application/json
{
email: bob@contoso.com
}
Если пользователь не существует, ответ должен иметь значение HTTP 200.
Если пользователь существует, ответ должен быть HTTP 409.
Запись сопоставления регионов пользователей
API используется во время регистрации для записи региона, в котором пользователь зарегистрировался.
Запрос будет следующим:
POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json
{
"email": "bob@contoso.com"
}
Если пользователь существует, ответ должен иметь значение HTTP 200.
Если пользователь существует, ответ должен быть HTTP 409.
Возвращает регион, в котором находится пользователь
API используется во время входа, чтобы определить, в каком регионе пользователь зарегистрировался. Это указывает, требуется ли выполнять проверку подлинности между клиентами.
Запрос будет следующим:
POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json
{
"email": "bob@contoso.com"
}
Ответ должен быть http 200 с зарегистрированным пользователем регионом и objectId.
{
"objectId": "460f9ffb-8b6b-458d-a5a4-b8f3a6816fc2",
"region": "APAC"
}
API должен ответить http 409, если пользователь не существует или обнаруживает ошибку.
Запись пароля между клиентами
API используется во время потока сброса пароля для записи нового пароля пользователей в другом регионе, в котором они сбрасывают пароль.
Запрос будет следующим:
POST /writePasswordCrossTenant HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json
{
"objectId": "460f9ffb-8b6b-458d-a5a4-b8f3a6816fc2",
"password": "some!strong123STRING"
}
Ответ должен быть HTTP 200, если процесс выполнен успешно, или HTTP 409 при возникновении ошибки.
Конфигурация Azure AD B2C на основе региона
В следующих разделах подготавливается клиент Azure AD B2C для отслеживания региона, в котором пользователь зарегистрировалась, и выполнения проверки подлинности между арендаторами или сброса пароля при необходимости.
Настройка настраиваемой политики регистрации
Во время регистрации необходимо убедиться, что проверка пользователь не существует ни в одном другом клиенте, и записать сопоставление пользователей и региона пользователя во внешнюю таблицу.
Измените LocalAccountSignUpWithLogonEmail
технический профиль в начальном пакете Azure AD B2C следующим образом:
<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 будет выполнять следующую логику:
Получите маркер для вызова защищенных конечных точек API с помощью технического
REST-getTokenforExternalApiCalls
профиля.- Следуйте этой документации, чтобы получить и защитить API с помощью маркера носителя Microsoft Entra.
Убедитесь, что пользователь уже существует в сопоставлении пользователей и регионов через защищенную внешнюю конечную точку REST API:
Этот вызов API выполняется перед всеми регистрациями. Крайне важно убедиться, что этот API имеет соответствующие механизмы балансировки нагрузки, устойчивости и отработки отказа, чтобы обеспечить соответствие требованиям к времени доступности.
Ниже приведен пример технического профиля для запроса сопоставления пользовательского региона через внешний REST API.
<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>
Этот API должен отвечать http 409, если пользователь существует, с соответствующим сообщением об ошибке, которое будет отображаться на экране. В противном случае ответьте http 200, если пользователь не существует.
Запись сопоставления пользовательского региона с помощью защищенной внешней конечной точки REST API
Этот вызов API выполняется до завершения регистрации. Очень важно убедиться, что этот API имеет соответствующие механизмы балансировки нагрузки, устойчивости и отработки отказа, чтобы обеспечить соответствие требованиям к времени доступности.
Ниже приведен пример технического профиля для записи сопоставления пользовательского региона с помощью внешнего REST API.
<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> ```
Настройка настраиваемой политики входа
Во время входа необходимо определить расположение профиля пользователей и проверить их подлинность в клиенте Azure AD B2C, в котором находится их профиль.
Измените SelfAsserted-LocalAccountSignin-Email
технический профиль в начальном пакете Azure AD B2C, чтобы выполнить поиск в регионе пользователя и выполнить проверку подлинности между клиентами, если пользователь находится из другого региона к региону клиента, к которому он подключен. Обновите как 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 будет выполнять следующую логику, когда пользователь отправит свои учетные данные:
Получите маркер для вызова защищенных конечных точек API с помощью технического
REST-getTokenforExternalApiCalls
профиля.- Следуйте этой документации, чтобы получить и защитить API с помощью маркера носителя Microsoft Entra.
Поиск сопоставления пользовательского региона с помощью защищенной внешней конечной точки REST API
Этот вызов API выполняется перед всеми регистрациями. Крайне важно убедиться, что этот API имеет соответствующие механизмы балансировки нагрузки, устойчивости и отработки отказа, чтобы обеспечить соответствие требованиям к времени доступности.
Ниже приведен пример технического профиля для запроса сопоставления пользовательского региона через внешний REST API.
<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>
Выполните проверку подлинности локальной учетной записи с помощью технического
login-NonInteractive
профиля для пользователей, которые зарегистрировались в этом клиенте. Это технический профиль по умолчанию, найденный в начальном пакете Azure AD B2C.Условно выполните проверку подлинности между клиентами с помощью технических профилей
REST-login-NonInteractive-[region]
для каждого соответствующего региона.При этом также будет получен маркер MS API Graph от домашнего клиента пользователей. Зарегистрируйте регистрацию приложения в собственном приложении в каждом региональном клиенте с разрешениями на MS API Graph для делегированного разрешения
user.read
.Ниже приведен пример технического профиля для сопоставления пользовательского региона с помощью внешнего REST API.
<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>
Замените
<yourb2ctenant>
в наServiceUrl
клиент, на который необходимо ориентироваться для проверки подлинности.Используйте регистрацию
ApplicationId
приложения, чтобы заполнитьDefaultValue
для входногоapac_client_id
утверждения.
Условное получение профиля пользователя с помощью вызова REST API для нескольких клиентов с помощью технических профилей
REST-fetchUserProfile-[region]
для каждого соответствующего региона.Ниже приведен пример технического профиля для чтения профиля пользователя через MS API Graph:
<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>
Настройка настраиваемой политики сброса пароля
Во время сброса пароля необходимо определить расположение профиля пользователей и обновить пароль для клиента Azure AD B2C, в котором находится профиль пользователя.
Измените LocalAccountSignUpWithLogonEmail
технический профиль в начальном пакете Azure AD B2C, чтобы выполнить поиск пользователя в регионе пользователя, и обновите пароль в соответствующем клиенте. Обновите как 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 будет выполнять следующую логику, когда пользователь отправляет проверенное сообщение электронной почты для обновления пароля:
Получение маркера для вызова защищенных конечных точек API
Поиск сопоставления пользовательского региона через защищенную внешнюю конечную точку REST API
- Этот вызов API выполняется до всех попыток сброса пароля. Очень важно убедиться, что этот API имеет соответствующие механизмы балансировки нагрузки, устойчивости и отработки отказа для соблюдения требований к времени безотказной работы.
Измените LocalAccountWritePasswordUsingObjectId
технический профиль, чтобы записать новый пароль в локальный клиент или условно в межрегиональная клиент.
<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 будет выполнять следующую логику, когда пользователь отправляет новый пароль:
Запишите новый пароль пользователей в каталог, если пользователь существовал в клиенте EMEA (этот клиент).
Условно, запишите новый пароль в профиль пользователя в регионе, где находится профиль пользователя, с помощью вызова REST API.
<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>