Adición de un conector de API a un flujo de usuario de registro

Importante

A partir del 1 de mayo de 2025, Azure AD B2C ya no estará disponible para ser adquirido por nuevos clientes. Obtenga más información en nuestras preguntas más frecuentes.

Antes de comenzar, use el Elegir un tipo de directiva selector en la parte superior de esta página para elegir el tipo de directiva que está configurando. Azure Active Directory B2C ofrece dos métodos para definir el modo en que los usuarios interactúan con las aplicaciones: por medio de flujos de usuario predefinidos o de directivas personalizadas totalmente configurables. Los pasos necesarios en este artículo son diferentes para cada método.

Como desarrollador o administrador de TI, puede usar conectores de API para integrar los flujos de usuario de registro con las API REST para personalizar la experiencia de registro e integrarse con sistemas externos. Al final de este tutorial, podrá crear un flujo de usuario de Azure AD B2C que interactúe con los servicios de API REST para modificar las experiencias de registro.

Puede crear un punto de conexión de API mediante uno de nuestros ejemplos.

En este escenario, agregaremos la capacidad de que los usuarios escriban un número de fidelidad en la página de registro de Azure AD B2C. La API REST valida si la combinación de correo electrónico y número de fidelidad se asigna a un código promocional. Si la API REST encuentra un código promocional para este usuario, se devolverá a Azure AD B2C. Por último, el código promocional se insertará en las notificaciones del token para que la aplicación lo consuma.

También puede diseñar la interacción como un paso de orquestación. Esto es adecuado cuando la API REST no va a validar datos en pantalla y siempre devuelve notificaciones. Para más información, consulte Guía: Integración de intercambios de declaraciones de la API REST como paso de orquestación en el recorrido del usuario de Azure AD B2C.

Prerrequisitos

• Cree un flujo de usuario para que los usuarios se registren e inicien sesión en la aplicación.
• Registre una aplicación web.

• Siga los pasos de Introducción a las directivas personalizadas en Active Directory B2C. En este tutorial se explica cómo actualizar archivos de directiva personalizados para usar la configuración del inquilino de Azure AD B2C.
• Registre una aplicación web.

Creación de un conector de API

Para usar un conector de API, primero debe crear el conector de API y, después, habilitarlo en un flujo de usuario.

1. Inicie sesión en Azure Portal.

2. En Servicios de Azure, seleccione Azure AD B2C.

3. Seleccione Conectores de API y, a continuación, seleccione Nuevo conector de API.

   

4. Escriba el nombre para mostrar de la llamada. Por ejemplo, Valide la información del usuario.

5. Proporcione la URL del punto de conexión para la solicitud de API.

6. Elija el tipo de autenticación y configure la información de autenticación para llamar a la API. Obtenga más información sobre la Protección de un conector de API.

   

7. Haga clic en Guardar.

Solicitud enviada a la API

Un conector de API se materializa como una solicitud HTTP POST y envía los atributos de usuario ("claims") como pares de clave y valor en un cuerpo JSON. Los atributos se serializan de forma similar a las propiedades de usuario de Microsoft Graph.

Solicitud de ejemplo

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "<step-name>",
 "client_id":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

Solo se pueden enviar en la solicitud las propiedades de usuario y los atributos personalizados que se enumeran en la experiencia Azure AD B2C>Atributos de usuario.

Los atributos personalizados existen en el formato extension_<extensions-app-id>_CustomAttribute en el directorio. La API esperará recibir las notificaciones con este mismo formato serializado. Para más información sobre los atributos personalizados, consulte Definición de atributos personalizados en Azure AD B2C.

Además, estas notificaciones normalmente se envían en todas las solicitudes:

• Configuraciones regionales de interfaz de usuario ("ui_locales"): configuraciones regionales de un usuario final configuradas en su dispositivo. La API puede usar esto para devolver respuestas internacionalizadas.
• Paso ('paso'): paso o punto en el flujo de usuario para el que se invocó el conector de API. Los valores son:
  • PostFederationSignup : corresponde a "Después de federar con un proveedor de identidades durante el registro"
  • PostAttributeCollection : corresponde a "Antes de crear el usuario"
  • PreTokenIssuance : corresponde a "Antes de enviar el token (versión preliminar)". Más información sobre este paso
• ID de cliente ('client_id'): el valor appId de la aplicación a la que se autentica un usuario final en un flujo de usuario. No es el valor appId de la aplicación de recursos de los tokens de acceso.
• Dirección de correo electrónico ("email") o identidades ("identidades"): la API puede usar estas notificaciones para identificar al usuario final que se autentica en la aplicación.

Importante

Si una notificación no tiene un valor en el momento en que se llama al punto de conexión de la API, la notificación no se enviará a la API. La API debe estar diseñada para comprobar y controlar explícitamente el caso en el que una notificación no está en la solicitud.

Habilitación del conector de API en un flujo de usuario

Siga estos pasos para agregar un conector de API a un flujo de usuario de registro.

1. Inicie sesión en Azure Portal.

2. En Servicios de Azure, seleccione Azure AD B2C.

3. Seleccione Flujos de usuario y, después, seleccione el flujo de usuario para el que desea habilitar el conector de API.

4. Seleccione Conectores de API y, después, seleccione los puntos de conexión de API que desea invocar en los pasos siguientes del flujo de usuario:

   • Después de federarse con un proveedor de identidad durante el registro
   • Antes de crear el usuario
   • Antes de enviar el token (versión preliminar)

   

5. Haga clic en Guardar.

Estos pasos solo existen para registrarse e iniciar sesión (recomendado) y registrarse (recomendado), pero solo se aplican a la parte de registro de la experiencia.

Después de la federación con un proveedor de identidades durante el registro

En este paso, se invoca un conector de API en el proceso de registro inmediatamente después de que el usuario se autentique con un proveedor de identidades (como Google, Facebook y Microsoft Entra ID). Este paso precede a la página de recopilación de atributos, que es el formulario que se muestra al usuario para recopilar los atributos de usuario. Este paso no se invoca si un usuario se registra con una cuenta local.

Solicitud de ejemplo enviada a la API en este paso

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [ 
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "step": "PostFederationSignup",
 "client_id":"<guid>",
 "ui_locales":"en-US"
}

Las declaraciones exactas enviadas a la API dependen de la información proporcionada por el proveedor de identidad. Siempre se envía "email".

Tipos de respuesta esperados de la API web en este paso

Cuando la API web recibe una solicitud HTTP de Microsoft Entra ID durante un flujo de usuario, puede devolver estas respuestas:

• Respuesta de continuación
• Respuesta de bloqueo

Respuesta de continuación

Una respuesta de continuación indica que el flujo de usuario debe continuar en el paso siguiente: la página de colección de atributos.

En una respuesta de continuación, la API puede devolver notificaciones. Si la API devuelve una reclamación, esta realiza lo siguiente:

• Rellena previamente el campo de entrada en la página de colección de atributos.

Vea un ejemplo de una respuesta continua.

Respuesta de bloqueo

Una respuesta de bloqueo termina el flujo de usuario. La API puede emitirla intencionadamente para detener el flujo de usuario y mostrar una página de bloqueo al usuario. La página de bloqueo muestra el mensaje userMessage proporcionado por la API.

Vea un ejemplo de una respuesta de bloqueo.

Antes de crear el usuario

Después de la página de recopilación de atributos, se invoca un conector de API en este paso del proceso de registro, si se incluye uno. Este paso siempre se invoca antes de crear una cuenta de usuario.

Solicitud de ejemplo enviada a la API en este paso

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "PostAttributeCollection",
 "client_id":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

Las afirmaciones que se envían a la API dependen de la información recopilada del usuario o proporcionada por el proveedor de identidad.

Tipos de respuesta esperados de la API web en este paso

Cuando la API web recibe una solicitud HTTP de Microsoft Entra ID durante un flujo de usuario, puede devolver estas respuestas:

• Respuesta de continuación
• Respuesta de bloqueo
• Respuesta de validación

Respuesta de continuación

Una respuesta de continuación indica que el flujo de usuario debe continuar en el paso siguiente: creación del usuario en el directorio.

En una respuesta de continuación, la API puede devolver notificaciones. Si la API devuelve una reclamación, esta realiza lo siguiente:

• Invalida cualquier valor que ya haya proporcionado un usuario en la página de la colección de atributos.

Para escribir notificaciones en el directorio al realizar el registro que no se deben recopilar del usuario, debe seleccionar las notificaciones en Atributos de usuario del flujo de usuario, acción que de forma predeterminada pedirá valores al usuario, pero puede usar JavaScript o CSS personalizados para ocultar los campos de entrada a un usuario final.

Vea un ejemplo de una respuesta continua.

Respuesta de bloqueo

Una respuesta de bloqueo termina el flujo de usuario. La API puede emitirla intencionadamente para detener el flujo de usuario y mostrar una página de bloqueo al usuario. La página de bloqueo muestra el mensaje userMessage proporcionado por la API.

Vea un ejemplo de una respuesta de bloqueo.

Respuesta de error de validación

Cuando la API responde con una respuesta de error de validación, el flujo de usuario permanece en la página de recopilación de atributos y userMessage se muestra al usuario. El usuario puede editar el formulario y volver a enviarlo. Este tipo de respuesta se puede usar para la validación de datos de entrada.

Vea un ejemplo de una respuesta de error de validación.

Antes de enviar el token (versión preliminar)

Importante

Los conectores de API que se usan en este paso están en versión preliminar. Para obtener más información sobre las versiones preliminares, consulte Términos del producto para Online Services.

Se invoca un conector de API en este paso cuando un token está a punto de emitirse durante los inicios de sesión y los registros. Se puede usar un conector de API en este paso para enriquecer el token con valores de reclamaciones de orígenes externos.

Solicitud de ejemplo enviada a la API en este paso

POST <API-endpoint>
Content-type: application/json

{
 "clientId": "11112222-bbbb-3333-cccc-4444dddd5555",
 "step": "PreTokenApplicationClaims",
 "ui_locales":"en-US",
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
}

Las reclamaciones que se envían a la API dependen de la información definida para el usuario.

Tipos de respuesta esperados de la API web en este paso

Cuando la API web recibe una solicitud HTTP de Microsoft Entra ID durante un flujo de usuario, puede devolver estas respuestas:

• Respuesta de continuación

Respuesta de continuación

Una respuesta de continuación indica que el flujo de usuario debe continuar con el paso siguiente: emitir el token.

En una respuesta de continuación, la API puede devolver notificaciones adicionales. Una notificación devuelta por la API que desea devolver en el token debe ser una notificación integrada o definida como un atributo personalizado y debe seleccionarse en la configuración de notificaciones de aplicación del flujo de usuario.

El valor de notificación del token es el devuelto por la API, no el valor del directorio. La respuesta de la API no puede sobrescribir algunos valores de notificación. Las notificaciones que puede devolver la API corresponden al conjunto que se encuentra en Atributos de usuario, con la excepción de email.

Vea un ejemplo de una respuesta continua.

Nota:

La API solo se invoca durante una autenticación inicial. Al usar tokens de actualización para obtener de forma silenciosa nuevos tokens de acceso o identificador, el token incluirá los valores evaluados durante la autenticación inicial.

Respuestas de ejemplo

Ejemplo de una respuesta de continuación

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "Continue",
    "postalCode": "12349", // return claim
    "extension_<extensions-app-id>_CustomAttribute": "value" // return claim
}

Parámetro	Tipo	Obligatorio	Descripción
Versión	Cuerda	Sí	Versión de la API.
acción	Cuerda	Sí	El valor debe ser Continue.
<atributoDeUsuarioIntegrado>	<tipo de atributo>	No	Los valores devueltos pueden sobrescribir los valores recopilados de un usuario.
<extension_{extensions-app-id}_AtributoPersonalizado>	<tipo de atributo>	No	La notificación no necesita contener _<extensions-app-id>_, es opcional. Los valores devueltos pueden sobrescribir los valores recopilados de un usuario.

Ejemplo de una respuesta de bloqueo

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "There was a problem with your request. You are not able to sign up at this time. Please contact your system administrator",
}

Parámetro	Tipo	Obligatorio	Descripción
Versión	Cuerda	Sí	Versión de la API.
acción	Cuerda	Sí	El valor debe ser ShowBlockPage.
mensajeDeUsuario	Cuerda	Sí	Mensaje que se va a mostrar al usuario.

Experiencia del usuario final con una respuesta de bloqueo

Ejemplo de una respuesta de error de validación

HTTP/1.1 400 Bad Request
Content-type: application/json

{
    "version": "1.0.0",
    "status": 400,
    "action": "ValidationError",
    "userMessage": "Please enter a valid Postal Code."
}

Parámetro	Tipo	Obligatorio	Descripción
Versión	Cuerda	Sí	Versión de la API.
acción	Cuerda	Sí	El valor debe ser ValidationError.
estado	Entero/cadena	Sí	Debe ser un valor 400 o "400" para una respuesta ValidationError.
mensajeDeUsuario	Cuerda	Sí	Mensaje que se va a mostrar al usuario.

Nota:

El código de estado HTTP debe ser "400" además del valor de "status" en el cuerpo de la respuesta.

Experiencia del usuario final con una respuesta de error de validación

Preparación de un punto de conexión de LA API REST

Para este tutorial, debe tener una API REST que valide si una dirección de correo electrónico está registrada en el sistema back-end con un identificador de fidelidad. Si se registra, la API REST debe devolver un código de promoción de registro, que el cliente puede usar para comprar bienes dentro de la aplicación. De lo contrario, la API REST debe devolver un mensaje de error HTTP 409: "El identificador de fidelidad '{id. de fidelidad}' no está asociado a la dirección de correo electrónico '{email}'".

En el código JSON siguiente se muestran los datos que Azure AD B2C enviará al punto de conexión de la API REST.

{
    "email": "User email address",
    "language": "Current UI language",
    "loyaltyId": "User loyalty ID"
}

Una vez que la API rest valida los datos, debe devolver un HTTP 200 (Correcto), con los siguientes datos JSON:

{
    "promoCode": "24534"
}

Si se produjo un error en la validación, la API REST debe devolver un HTTP 409 (Conflicto), con el userMessage elemento JSON. IEF espera la notificación userMessage que devuelve la API REST. Esta notificación se presentará como una cadena al usuario si se produce un error en la validación.

{
    "version": "1.0.1",
    "status": 409,
    "userMessage": "LoyaltyId ID '1234' is not associated with 'david@contoso.com' email address."
}

La configuración del punto de conexión de la API REST está fuera del ámbito de este artículo. Hemos creado un ejemplo de Azure Functions . Puede acceder al código completo de la función de Azure en GitHub.

Definir reclamaciones

Una notificación proporciona un almacenamiento temporal de datos durante la ejecución de una directiva de Azure AD B2C. Puede declarar reclamaciones en la sección de esquema de reclamaciones.

1. Abra el archivo de extensiones de su política. Por ejemplo: SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
2. Busque el elemento BuildingBlocks . Si el elemento no existe, agréguelo.
3. Busque el elemento ClaimsSchema . Si el elemento no existe, agréguelo.
4. Agregue los siguientes reclamos al elemento ClaimsSchema.

<ClaimType Id="loyaltyId">
  <DisplayName>Your loyalty ID</DisplayName>
  <DataType>string</DataType>
  <UserInputType>TextBox</UserInputType>
</ClaimType>
<ClaimType Id="promoCode">
  <DisplayName>Your promo code</DisplayName>
  <DataType>string</DataType>
  <UserInputType>Paragraph</UserInputType>
</ClaimType>
  <ClaimType Id="userLanguage">
  <DisplayName>User UI language (used by REST API to return localized error messages)</DisplayName>
  <DataType>string</DataType>
</ClaimType>

Adición del perfil técnico de la API RESTful

Un perfil técnico RESTful proporciona soporte técnico para interactuar con su propio servicio RESTful. Azure AD B2C envía datos al servicio RESTful en una InputClaims colección y recibe los datos de nuevo en una OutputClaims colección. Busque el elemento ClaimsProviders y agregue un nuevo proveedor de notificaciones de la siguiente manera:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-ValidateProfile">
      <DisplayName>Check loyaltyId Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <!-- Set the ServiceUrl with your own REST API endpoint -->
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/ValidateProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
        <Item Key="AuthenticationType">None</Item>
        <!-- REMOVE the following line in production environments -->
        <Item Key="AllowInsecureAuthInProduction">true</Item>
      </Metadata>
      <InputClaims>
        <!-- Claims sent to your REST API -->
        <InputClaim ClaimTypeReferenceId="loyaltyId" />
        <InputClaim ClaimTypeReferenceId="email" />
        <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
      </InputClaims>
      <OutputClaims>
        <!-- Claims parsed from your REST API -->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

En este ejemplo, userLanguage se enviará al servicio REST como lang dentro de la carga JSON. El valor de la notificación userLanguage contiene el identificador de idioma del usuario actual. Para obtener más información, consulte resolución de reclamaciones.

Configuración del perfil técnico de la API RESTful

Después de implementar la API REST, establezca los metadatos del REST-ValidateProfile perfil técnico para reflejar su propia API REST, entre las que se incluyen:

• ServiceUrl. Establezca la dirección URL del punto de conexión de la API REST.
• SendClaimsIn. Especifique cómo se envían las notificaciones de entrada al proveedor de notificaciones RESTful.
• AuthenticationType. Establezca el tipo de autenticación que realiza el proveedor de notificaciones RESTful.
• AllowInsecureAuthInProduction. En un entorno de producción, asegúrese de establecer estos metadatos en . true

Consulte los metadatos del perfil técnico RESTful para obtener más configuraciones.

Los comentarios anteriores AuthenticationType y AllowInsecureAuthInProduction especifican los cambios que debe realizar al pasar a un entorno de producción. Para obtener información sobre cómo proteger las API de RESTful para producción, consulte Secure RESTful API (API segura de RESTful).

Validar la entrada del usuario

Para obtener el número de fidelidad del usuario durante el registro, debe permitir que el usuario escriba estos datos en la pantalla. Agregue la notificación de salida loyaltyId a la página de registro. Para hacerlo, agréguela al elemento OutputClaims de la sección del perfil técnico de registro existente. Especifique toda la lista de notificaciones de salida para controlar el orden en que se presentan las notificaciones en la pantalla.

Agregue la referencia del perfil técnico de validación al perfil técnico de registro, que llama a REST-ValidateProfile. El nuevo perfil técnico de validación se agregará a la parte superior de la <ValidationTechnicalProfiles> colección definida en la directiva base. Este comportamiento significa que solo después de una validación correcta, Azure AD B2C pasa a crear la cuenta en el directorio.

1. Busque el elemento ClaimsProviders. Agregue un nuevo proveedor de reclamaciones de la siguiente manera:

   <ClaimsProvider>
     <DisplayName>Local Account</DisplayName>
     <TechnicalProfiles>
       <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
         <OutputClaims>
           <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
           <OutputClaim ClaimTypeReferenceId="newPassword" Required="true"/>
           <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true"/>
           <OutputClaim ClaimTypeReferenceId="displayName"/>
           <OutputClaim ClaimTypeReferenceId="givenName"/>
           <OutputClaim ClaimTypeReferenceId="surName"/>
           <!-- Required to present the text box to collect the data from the user -->
           <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
           <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
           to subsequent orchestration steps and token issuance-->
           <OutputClaim ClaimTypeReferenceId="promoCode" />
         </OutputClaims>
         <ValidationTechnicalProfiles>
           <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile" />
         </ValidationTechnicalProfiles>
       </TechnicalProfile>
     </TechnicalProfiles>
   </ClaimsProvider>
   <ClaimsProvider>
     <DisplayName>Self Asserted</DisplayName>
     <TechnicalProfiles>
       <TechnicalProfile Id="SelfAsserted-Social">
         <InputClaims>
           <InputClaim ClaimTypeReferenceId="email" />
         </InputClaims>
           <OutputClaims>
           <OutputClaim ClaimTypeReferenceId="email" />
           <OutputClaim ClaimTypeReferenceId="displayName"/>
           <OutputClaim ClaimTypeReferenceId="givenName"/>
           <OutputClaim ClaimTypeReferenceId="surname"/>
           <!-- Required to present the text box to collect the data from the user -->
           <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
           <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
           to subsequent orchestration steps and token issuance-->
           <OutputClaim ClaimTypeReferenceId="promoCode" />
         </OutputClaims>
         <ValidationTechnicalProfiles>
           <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile"/>
         </ValidationTechnicalProfiles>
       </TechnicalProfile>
     </TechnicalProfiles>
   </ClaimsProvider>
   

Incluir una reclamación en el token

Para devolver la notificación del código de promoción a la aplicación de usuario de confianza, agregue una notificación de salida al archivo SocialAndLocalAccounts/SignUpOrSignIn.xml. La notificación de salida permitirá agregar la notificación al token después de un recorrido del usuario correcto y se enviará a la aplicación. Modifique el elemento de perfil técnico en la sección de usuario de confianza para agregar promoCode como una notificación de salida.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
      <OutputClaim ClaimTypeReferenceId="promoCode" DefaultValue="" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Probar la política personalizada

1. Inicie sesión en Azure Portal.
2. Si tiene acceso a varios inquilinos, seleccione el icono Configuración en el menú superior para cambiar a su inquilino de Microsoft Entra ID desde el menú Directorios y suscripciones.
3. Elija Todos los servicios en la esquina superior izquierda de Azure Portal y busque y seleccione Registros de aplicaciones.
4. Seleccione Marco de experiencia de identidad.
5. Seleccione Cargar directiva personalizada y, a continuación, cargue los archivos de directiva que ha cambiado: TrustFrameworkExtensions.xmly SignUpOrSignin.xml.
6. Seleccione la directiva de registro o de inicio de sesión que cargó y haga clic en el botón Ejecutar ahora .
7. Debería poder registrarse con una dirección de correo electrónico.
8. Haga clic en el vínculo Registrarse ahora .
9. En Su identificador de fidelidad, escriba 1234 y haga clic en Continuar. En este momento, debería recibir un mensaje de error de validación.
10. Cambie a otro valor y haga clic en Continuar.
11. El token enviado de vuelta a la aplicación contiene la notificación promoCode.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584295703,
  "nbf": 1584292103,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/",
  "aud": "22223333-cccc-4444-dddd-5555eeee6666",
  "acr": "b2c_1a_signup_signin",
  "nonce": "defaultNonce",
  "iat": 1584292103,
  "auth_time": 1584292103,
  "name": "Emily Smith",
  "email": "emily@outlook.com",
  "given_name": "Emily",
  "family_name": "Smith",
  "promoCode": "84362"
  ...
}

Procedimientos recomendados y solución de problemas

Uso de funciones de nube sin servidor

Las funciones sin servidor, como los desencadenadores HTTP de Azure Functions, proporcionan una manera de crear puntos de conexión de API para usarlos con el conector de API. Puede usar la función de nube sin servidor para, por ejemplo, crear la lógica de validación y limitar los registros a dominios específicos. La función de nube sin servidor también puede llamar e invocar a otras API web, almacenes de datos y otros servicios en la nube para escenarios complejos.

procedimientos recomendados

Asegúrate de que:

• La API sigue los contratos de solicitud y respuesta de la API, tal y como se describe anteriormente.
• La URL del punto de conexión del conector de API apunta al punto de conexión de API correcto.
• La API verifica explícitamente los valores null de las declaraciones recibidas de las que depende.
• La API implementa un método de autenticación descrito en Protección de un conector de API.
• La API responde lo más rápido posible para garantizar una experiencia de usuario fluida.
  • Azure AD B2C esperará un máximo de 10 segundos para recibir una respuesta. Si no se recibe ninguna, realiza un intento más (reintento) de llamar a la API.
  • Si usa una función sin servidor o un servicio web escalable, use un plan de hospedaje que mantenga la API "activa" o "caliente" en producción. Para Azure Functions, se recomienda usar como mínimo el plan Premium en producción.
• Garantice una alta disponibilidad de la API.
• Supervise y optimice el rendimiento de las API de nivel inferior, las bases de datos u otras dependencias de la API.

Importante

Los puntos de conexión deben cumplir los requisitos de seguridad de Azure AD B2C. Las versiones anteriores de TLS y los cifrados están en desuso. Para obtener más información, consulte Requisitos de TLS y del conjunto de cifrado de Azure AD B2C.

Uso del registro

En general, resulta útil usar las herramientas de registro que habilita el servicio de API web, como Application Insights, para supervisar la API en busca de códigos de error inesperados, excepciones y rendimiento deficiente.

• Supervise los códigos de estado HTTP que no sean HTTP 200 ni 400.
• Un código de estado HTTP 401 o 403 suele indicar que hay un problema con la autenticación. Compruebe la capa de autenticación de la API y la configuración correspondiente en el conector de API.
• Use niveles más agresivos de registro (por ejemplo, "trace" o "debug") en el desarrollo, si es necesario.
• Monitoree la API en busca de tiempos de respuesta prolongados.

Además, Azure AD B2C registra metadatos sobre las transacciones de API que se producen durante las autenticaciones de usuario a través de un flujo de usuario. Para encontrarlos:

1. Vaya a Azure AD B2C.
2. En Actividades, seleccione Registros de auditoría.
3. Filtre la vista de lista: en Fecha, seleccione el intervalo de tiempo que desee y, en Actividad, seleccione An API was called as part of a user flow (Una API se llamó como parte de un flujo de usuario).
4. Inspeccione los registros individuales. Cada fila representa un conector de API que intenta llamarse durante un flujo de usuario. Si se produce un error en una llamada API y se produce un reintento, todavía se representa como una sola fila. numberOfAttempts indica el número de veces que se llamó a la API. Este valor puede ser 1o 2. En los registros se detalla otra información sobre la llamada API.

Uso de funciones de nube sin servidor

Las funciones en la nube sin servidor, como los desencadenadores HTTP en Azure Functions, proporcionan una manera sencilla, de alta disponibilidad y de alto rendimiento para crear puntos de conexión de API que se usen como conectores de API.

procedimientos recomendados

Asegúrate de que:

• La API verifica explícitamente los valores null de las declaraciones recibidas de las que depende.
• La API implementa un método de autenticación descrito en Protección de un conector de API.
• La API responde lo más rápido posible para garantizar una experiencia de usuario fluida.
  • Si usa una función sin servidor o un servicio web escalable, use un plan de hospedaje que mantenga la API "activa" o "caliente" en producción. En Azure Functions, se recomienda usar como mínimo el plan Premium.
• Garantice una alta disponibilidad de la API.
• Supervise y optimice el rendimiento de las API de nivel inferior, las bases de datos u otras dependencias de la API.

Importante

Los puntos de conexión deben cumplir los requisitos de seguridad de Azure AD B2C. Las versiones anteriores de TLS y los cifrados están en desuso. Para obtener más información, consulte Requisitos de TLS y del conjunto de cifrado de Azure AD B2C.

Uso del registro

En general, resulta útil usar las herramientas de registro que habilita el servicio de API web, como Application Insights, para supervisar la API en busca de códigos de error inesperados, excepciones y rendimiento deficiente.

• Supervise los códigos de estado HTTP que no sean HTTP 200 ni 400.
• Un código de estado HTTP 401 o 403 suele indicar que hay un problema con la autenticación. Compruebe la capa de autenticación de la API y la configuración correspondiente en el conector de API.
• Use niveles más agresivos de registro (por ejemplo, "trace" o "debug") en el desarrollo, si es necesario.
• Monitoree la API en busca de tiempos de respuesta prolongados.

Pasos siguientes

• Empiece a trabajar con nuestros ejemplos.
• Protección del conector de API

• Tutorial: Integración de intercambios de notificaciones de API de REST en los recorridos de usuario de Azure AD B2C como un paso de orquestación
• Protección del conector de API
• Referencia: Perfil técnico RESTful