Prueba de concepto del marco de identidad global de Azure Active Directory B2C para la configuración basada en regiones
En la sección siguiente se describe cómo crear implementaciones de prueba de concepto para la orquestación basada en regiones. Las directivas personalizadas de Azure Active Directory B2C (Azure AD B2C) completadas se pueden encontrar aquí.
Enfoque basado en regiones
Cada inquilino de Azure AD B2C regional requerirá una directiva personalizada de Azure AD B2C, que contenga las siguientes funcionalidades:
Recorrido de registro:
- Muestre una pantalla para recopilar el nombre, la contraseña y cualquier otro atributo del usuario
- Impida el registro si el usuario ya existe mediante la tabla de asignación de regiones de usuario
- Escriba el perfil de usuario en el inquilino local
- Escriba la asignación entre el nombre y la región de los usuarios en una tabla de asignación
- Emisión de un token a la aplicación
Recorrido de inicio de sesión:
- Mostrar pantalla de nombre de usuario y contraseña
- Realice una búsqueda del nombre de usuario y devuelva su región
- Realice una comprobación de credenciales locales o de credenciales entre inquilinos
- Lea el perfil de usuario del inquilino local, o bien a través de una llamada entre inquilinos
- Emisión de un token a la aplicación
Recorrido del restablecimiento de contraseña:
- Muestre una pantalla para validar el correo electrónico de los usuarios a través de OTP de correo electrónico
- Realice una búsqueda del nombre de usuario y devuelva su región
- Muestre una pantalla para capturar la nueva contraseña
- Escriba la nueva contraseña en el inquilino local o a través de una llamada entre inquilinos
- Emisión de un token a la aplicación
En el diagrama de bloques siguiente se muestra la prueba de concepto. En la guía se muestra cómo configurar los inquilinos de Azure AD B2C. La capa externa de la API y la tabla de búsqueda distribuida geográficamente no se incluyen como parte de esta guía.
Requisitos previos
Cree un inquilino por cada región con la que su empresa necesite ser compatible. Para esta prueba de concepto necesitará al menos dos inquilinos.
Implemente directivas personalizadas en los inquilinos.
Preparación de la capa de almacenamiento
Necesitará una capa de almacenamiento, que puede almacenar el correo electrónico, objectId y la región de los usuarios. De esta manera, es posible realizar un seguimiento y consultar dónde se registró el usuario. Para conservar estos datos, puede usar una tabla de Azure Storage.
Preparación de la capa de la API
Existen varias API que se usan como parte de la prueba de concepto para demostrar el enfoque basado en regiones.
Comprobar si el usuario ya existe
Durante el registro se usa una API para determinar si el usuario ya existe en alguna región.
La solicitud será la siguiente:
POST /doesUserExistInLookupTable HTTP/1.1
Host: yourapi.com
Content-Type: application/json
{
email: bob@contoso.com
}
Si el usuario no existe, la respuesta debe ser HTTP 200.
Si el usuario existe, la respuesta debe ser HTTP 409.
Registrar la asignación de regiones de usuarios
Durante el registro se usa una API para registrar la región en la que se ha registrado el usuario.
La solicitud será la siguiente:
POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json
{
"email": "bob@contoso.com"
}
Si el usuario existe, la respuesta debe ser HTTP 200.
Si el usuario existe, la respuesta debe ser HTTP 409.
Devuelve la región en la que existe el usuario
Durante el inicio de sesión se usa una API para determinar en qué región se ha registrado el usuario. Así, se indica si es necesario realizar una autenticación entre inquilinos.
La solicitud será la siguiente:
POST /userToRegionLookup HTTP/1.1
Host: yourapi.com
Authorization Bearer: <token>
Content-Type: application/json
{
"email": "bob@contoso.com"
}
La respuesta debe ser un HTTP 200 con la región registrada de los usuarios y objectId.
{
"objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"region": "APAC"
}
La API debe responder con un HTTP 409 si el usuario no existe o si encuentra un error.
Escribir contraseña entre inquilinos
Durante el flujo de restablecimiento de contraseña se usa una API para escribir la nueva contraseña de los usuarios en una región diferente a la que restablecieron su contraseña.
La solicitud será la siguiente:
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 respuesta debe ser HTTP 200 si el proceso se realiza correctamente, o bien HTTP 409 si se produce un error.
Configuración de Azure AD B2C basada en regiones
En las secciones siguientes se prepara el inquilino de Azure AD B2C para realizar un seguimiento de la región en la que el usuario se registró y realizar autenticaciones entre inquilinos o restablecimientos de contraseña si es necesario.
Registro de la configuración de directivas personalizadas
Durante el registro, hay que asegurarse de comprobar que el usuario no existe en ningún otro inquilino y escribir la asignación de regiones de usuario en una tabla externa.
Modifique el perfil técnico LocalAccountSignUpWithLogonEmail en el paquete de inicio de Azure AD B2C tal y como se muestra a continuación:
<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 llevará a cabo la siguiente lógica:
Obtenga un token para llamar a los puntos de conexión protegidos de la API mediante el perfil técnico
REST-getTokenforExternalApiCalls.- Siga la documentación que se encuentra aquí para obtener y proteger la API mediante un token de portador de Microsoft Entra.
Compruebe si el usuario ya existe en la asignación de regiones de usuario mediante el punto de conexión de la API de REST externa segura:
Esta llamada API se realiza antes de todos los registros, por lo que es fundamental asegurarse de que dicha API dispone de los mecanismos adecuados de equilibrio de carga, resistencia y conmutación por error para cumplir los requisitos de tiempo de actividad.
A continuación se muestra un ejemplo de perfil técnico para consultar una asignación de regiones de usuario a través de una API de REST externa:
<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>Si el usuario existe, esta API debe responder con HTTP 409, con el mensaje de error adecuado que se mostrará en pantalla. De lo contrario, si el usuario no existe, responda con un HTTP 200.
Escriba la asignación de regiones de usuario a través del punto de conexión de la API de REST externa segura
Esta llamada API se realiza antes de todos los registros, por lo que es fundamental asegurarse de que dicha API dispone de los mecanismos adecuados de equilibrio de carga, resistencia y conmutación por error para cumplir los requisitos de tiempo de actividad.
Un ejemplo de perfil técnico para escribir la asignación de regiones de usuario mediante una API de REST externa es el siguiente:
<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> ```
Inicio de sesión de configuración de directiva personalizada
Durante el inicio de sesión, hay que determinar la ubicación del perfil de los usuarios y autenticarlos en el inquilino de Azure AD B2C donde reside su perfil.
Modifique el perfil técnico SelfAsserted-LocalAccountSignin-Email en el paquete de inicio de Azure AD B2C a fin de realizar la búsqueda de regiones de usuario y realice la autenticación entre inquilinos cuando el usuario pertenezca a una región diferente a la del inquilino al que ha accedido. Actualice ValidationTechnicalProfiles como:
<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 llevará a cabo la siguiente lógica cuando el usuario envíe sus credenciales:
Obtenga un token para llamar a los puntos de conexión protegidos de la API mediante el perfil técnico
REST-getTokenforExternalApiCalls.- Siga la documentación que se encuentra aquí para obtener y proteger la API mediante un token de portador de Microsoft Entra.
Búsqueda de la asignación de regiones de usuario a través del punto de conexión de la API de REST externa segura
Esta llamada API se realiza antes de todos los registros, por lo que es fundamental asegurarse de que dicha API dispone de los mecanismos adecuados de equilibrio de carga, resistencia y conmutación por error para cumplir los requisitos de tiempo de actividad.
A continuación se muestra un ejemplo de perfil técnico para consultar una asignación de regiones de usuario a través de una API de REST externa:
<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>
Realice la autenticación de cuenta local a través del perfil técnico
login-NonInteractivepara los usuarios que se han registrado en este inquilino. Este es el perfil técnico predeterminado que se encuentra en el paquete de inicio de Azure AD B2C.Realice eventualmente una autenticación entre inquilinos a través de los perfiles técnicos
REST-login-NonInteractive-[region]para cada región correspondiente.También obtendrá un token de MS Graph API del inquilino principal de los usuarios. Registre un registro de aplicación nativa en cada inquilino regional con permisos para MS Graph API para el permiso delegado
user.read.Un ejemplo de perfil técnico para realizar la asignación de regiones de usuario a través de una API de REST externa es el siguiente:
<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>Reemplace
<yourb2ctenant>porServiceUrlcon el inquilino al que debe dirigirse para la autenticación.Use el registro de aplicación
ApplicationIdpara rellenar laDefaultValuepara la notificación de entradaapac_client_id.
Capture eventualmente el perfil de usuario mediante una llamada API de REST entre inquilinos a través mediante los perfiles técnicos
REST-fetchUserProfile-[region]de cada región correspondiente.Un ejemplo de perfil técnico para leer el perfil del usuario a través de MS Graph API es el siguiente:
<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>
Configuración de directivas personalizadas de restablecimiento de contraseña
Durante el restablecimiento de contraseña, se debe determinar la ubicación del perfil de usuario y actualizar la contraseña en el inquilino de Azure AD B2C donde reside el perfil de usuario.
Modifique el perfil técnico LocalAccountSignUpWithLogonEmail en el paquete de inicio de Azure AD B2C a fin de realizar la búsqueda de regiones de usuario y actualice la contraseña en el inquilino correspondiente. Actualice ValidationTechnicalProfiles como:
<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 llevará a cabo la siguiente lógica cuando el usuario envíe un correo electrónico verificado para actualizar la contraseña:
Obtención de un token para llamar a los puntos de conexión protegidos de la API
Búsqueda de la asignación de regiones de usuario a través del punto de conexión de la API de REST externa segura
- Esta llamada API se realiza antes de todos los intentos de restablecimiento de contraseña,resulta fundamental asegurarse de que dicha API dispone de los mecanismos adecuados de equilibrio de carga, resistencia y conmutación por error para cumplir los requisitos de tiempo de actividad.
Modifique el perfil técnico LocalAccountWritePasswordUsingObjectId para escribir la nueva contraseña en el inquilino local o eventualmente en el inquilino entre regiones.
<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 llevará a cabo la siguiente lógica cuando el usuario envíe una nueva contraseña:
Si el usuario existía en el inquilino de EMEA (este inquilino), escriba la nueva contraseña de los usuarios en el directorio.
Escriba eventualmente la nueva contraseña en el perfil de usuario en la región donde este reside mediante una llamada API de 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>