Tutorial: Configuración de Ping Identity con Azure Active Directory B2C para un acceso híbrido seguro

Importante

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

En este tutorial, aprenderá a ampliar las funcionalidades de Azure Active Directory B2C (Azure AD B2C) con PingAccess y PingFederate. PingAccess proporciona acceso a aplicaciones y API, y un motor de políticas para el acceso de usuarios autorizados. PingFederate es un servidor de federación empresarial para la autenticación de usuarios y el inicio de sesión único, una autoridad que permite a los clientes, empleados y socios acceder a las aplicaciones desde los dispositivos. Úselos juntos para habilitar el acceso híbrido seguro (SHA).

Muchos sitios de comercio electrónico y aplicaciones web expuestos a Internet se despliegan detrás de sistemas de proxy o un sistema de proxy inverso. Estos sistemas de proxy se autentican previamente, aplican políticas y enrutan el tráfico. Los escenarios típicos incluyen la protección de las aplicaciones web del tráfico web entrante y el suministro de una administración de sesión uniforme en las implementaciones de servidores distribuidos.

Por lo general, las configuraciones incluyen una capa de traducción de autenticación que externaliza la autenticación de la aplicación web. Los proxies inversos proporcionan el contexto de usuario autenticado a las aplicaciones web, como un valor de cabecera en forma clara o en formato de resumen. Las aplicaciones no usan tokens estándar del sector, como el lenguaje de marcado de aserción de seguridad (SAML), OAuth u OpenID Connect (OIDC). En su lugar, el proxy proporciona contexto de autenticación y mantiene la sesión con el agente de usuario final, como el navegador o la aplicación nativa. Como servicio que opera como intermediario, los proxies proporcionan un control significativo sobre las sesiones. El servicio de proxy es eficiente y escalable, no es un cuello de botella para las aplicaciones detrás del servicio de proxy. Este diagrama es un flujo de comunicaciones e implementación de proxy inverso.

Modernización

Si desea modernizar una plataforma de identidad en este tipo de configuraciones, es posible que haya preocupaciones de los clientes:

• Desacoplar el esfuerzo de modernizar las aplicaciones de la modernización de una plataforma de identidad
• Los entornos de coexistencia con autenticación moderna y heredada que consumen del proveedor de servicios de identidad modernizado
  • Impulse la coherencia de la experiencia del usuario final
  • Proporcionar una experiencia de inicio de sesión único en todas las aplicaciones

En respuesta a estas inquietudes, el enfoque de este tutorial es una integración de Azure AD B2C, PingAccess y PingFederate .

Entorno compartido

Una solución técnicamente viable y rentable es configurar el sistema de proxy inverso para usar el sistema de identidad modernizado, delegando la autenticación.
Los proxies son compatibles con los protocolos de autenticación modernos y utilizan la autenticación basada en redireccionamiento (pasiva) que envía a los usuarios al nuevo proveedor de identidad (IdP).

Azure AD B2C como proveedor de identidades

En Azure AD B2C, se definen directivas que controlan las experiencias y los comportamientos de los usuarios, también denominados recorridos de usuario. Cada directiva de este tipo expone un punto de conexión de protocolo que puede realizar la autenticación como un IdP. En la aplicación, no se requiere ningún tratamiento especial para determinadas directivas. Una aplicación realiza una solicitud de autenticación estándar al punto de conexión de autenticación específico del protocolo expuesto por una directiva.
Puede configurar Azure AD B2C para que comparta el mismo emisor entre directivas o un emisor único para cada directiva. Cada aplicación puede apuntar a directivas mediante una solicitud de autenticación nativa del protocolo, que impulsa los comportamientos del usuario, como el inicio de sesión, el registro y las ediciones de perfil. El diagrama muestra los flujos de trabajo de las aplicaciones OIDC y SAML.

El escenario puede ser un desafío para que las aplicaciones heredadas redirijan al usuario con precisión. Es posible que la solicitud de acceso a las aplicaciones no incluya el contexto de la experiencia del usuario. En la mayoría de los casos, la capa de proxy, o un agente integrado en la aplicación web, intercepta la solicitud de acceso.

Proxy inverso de PingAccess

Puede implementar PingAccess como proxy inverso. PingAccess intercepta una solicitud directa al actuar como intermediario o como un redireccionamiento desde un agente que se ejecuta en el servidor de aplicaciones web.

Configure PingAccess con OIDC, OAuth2 o SAML para la autenticación con un proveedor de autenticación ascendente. Puede configurar un IdP ascendente para este propósito en el servidor PingAccess. Consulte el siguiente diagrama.

Una implementación de Azure AD B2C típica donde hay directivas que exponen varios IdPs es un reto. PingAccess se configura con un solo IdP ascendente.

PingFederate como proxy de federación

Puede configurar PingFederate como un proveedor de autenticación, o un proxy, para los IdP ascendentes. Consulte el siguiente diagrama.

Use esta función para cambiar de forma contextual, dinámica o declarativa una solicitud entrante a una directiva de Azure AD B2C. Consulte el siguiente diagrama del flujo de secuencia de protocolo.

Prerrequisitos

Para empezar, necesitará lo siguiente:

• Una suscripción a Azure
  • Si no tiene una, obtenga una cuenta gratuita de Azure.
• Un inquilino de Azure AD B2C vinculado a su suscripción de Azure
• PingAccess y PingFederate implementados en contenedores de Docker o en máquinas virtuales (VM) de Azure

Conectividad y comunicación

Confirme la siguiente conectividad y comunicación.

• Servidor de PingAccess: se comunica con el servidor de PingFederate, el explorador cliente, OIDC, OAuth conocido y la detección de claves publicada por el servicio Azure AD B2C y el servidor de PingFederate.
• Servidor de PingFederate: se comunica con el servidor de PingAccess, el explorador cliente, OIDC, OAuth conocido y la detección de claves publicada por el servicio Azure AD B2C
• Aplicación AuthN heredada o basada en encabezados : se comunica hacia y desde el servidor PingAccess
• Aplicación de usuario de confianza de SAML: accede al tráfico del explorador desde el cliente. Accede a los metadatos de federación SAML publicados por el servicio Azure AD B2C.
• Aplicación moderna: accede al tráfico del explorador desde el cliente. Accede a OIDC, OAuth conocido y la detección de claves publicada por el servicio Azure AD B2C.
• API REST : llega al tráfico desde un cliente nativo o web. Accede a OIDC, OAuth conocido y la detección de claves publicada por el servicio Azure AD B2C

Configuración de Azure AD B2C

Puede utilizar flujos de usuario básicos o directivas avanzadas de Identity Enterprise Framework (IEF). PingAccess genera el punto de conexión de metadatos en función del valor de emisor, usando para ello el protocolo WebFinger como convención de detección. Para seguir esta convención, actualice el emisor de Azure AD B2C utilizando las propiedades de la política de flujo de usuario.

En las directivas avanzadas, la configuración incluye el elemento de metadatos IssuanceClaimPattern al valor AuthorityWithTfp en el perfil técnico del emisor JWT.

Configurar PingAccess y PingFederate

Use las instrucciones de las secciones siguientes para configurar PingAccess y PingFederate. Consulte el siguiente diagrama del flujo de usuario de integración general.

Configurar PingFederate como proveedor de tokens

Para configurar PingFederate como proveedor de tokens para PingAccess, asegúrese de la conectividad de PingFederate a PingAccess. Confirme la conectividad de PingAccess a PingFederate.

Configuración de una aplicación PingAccess para la autenticación basada en encabezados

Utilice las siguientes instrucciones para crear una aplicación PingAccess para la aplicación web de destino, para la autenticación basada en encabezados.

Creación de un host virtual

Importante

Cree un host virtual para cada aplicación.

Para crear un host virtual:

1. Vaya a Configuración>Acceso>Hosts Virtuales.
2. Seleccione Agregar host virtual.
3. En Host, introduzca la parte FQDN de la URL de la aplicación.
4. En el campo Puerto, escriba 443.
5. Haga clic en Guardar.

Crear una sesión web

Para crear una sesión web:

1. Vaya a Configuración>Acceder a>sesiones web.
2. Seleccione Agregar sesión web.
3. Introduzca un nombre para la sesión web.
4. Seleccione el tipo de cookie: JWT firmado o JWT cifrado.
5. Introduzca un valor único para Audiencia.
6. En Id. de cliente, escriba el identificador de aplicación de Microsoft Entra.
7. En Secreto de cliente, escriba la clave que generó para la aplicación en el identificador de Microsoft Entra.
8. (Opcional) Cree y use notificaciones personalizadas con Microsoft Graph API: seleccione Avanzado. Anule la selección de Perfil de solicitud y de Actualizar atributos de usuario. Obtenga más información sobre las notificaciones personalizadas: Inicio de sesión único basado en encabezado para aplicaciones locales con Microsoft Entra proxy de aplicaciones.
9. Seleccione Guardar.

Crear mapeo de identidad

Nota:

Puede usar una asignación de identidad con más de una aplicación, si todas ellas esperan los mismos datos en el encabezado.

Para crear un mapeo de identidad:

1. Vaya a Configuración>Acceso>Identity Mappings (Asignaciones de identidad).
2. Seleccione Add Identity Mapping (Agregar asignación de identidad).
3. Especifique un *Nombre.
4. Seleccione el tipo de asignación en Tipo de asignación de identidad de encabezado.
5. En la tabla Asignación de atributos , especifique las asignaciones necesarias. Por ejemplo

Nombre del atributo	Nombre del encabezado
"upn"	x-userprincipalname
'correo electrónico'	X-Correo electrónico
"oid"	X-oid
"scp"	Visor X
"amr"	X-AMR

6. Seleccione Guardar.

Crear un sitio

Nota:

En algunas configuraciones, un sitio puede contener varias aplicaciones. Puede usar un sitio con más de una aplicación, cuando corresponda.

Para crear un sitio:

1. Vaya aSitios>.
2. Seleccione Agregar sitio.
3. Introduzca el nombre del sitio.
4. Introduzca el destino del sitio. El destino es el par hostname:port para el servidor que aloja la aplicación. No introduzca la ruta de acceso de la aplicación en este campo. Por ejemplo, una aplicación at https://mysite:9999/AppName tiene un valor de destino de mysite:9999.
5. Indique si el destino espera conexiones seguras.
6. Si el destino espera conexiones seguras, establezca el grupo de certificados de confianza en Confiar en cualquiera.
7. Haga clic en Guardar.

Creación de una aplicación

Para crear una aplicación en PingAccess para cada aplicación de Azure que desee proteger.

1. Ir a Aplicaciones Principales>

2. Seleccione Agregar aplicación.

3. Especifique un nombre para la aplicación

4. Opcionalmente, introduzca una descripción para la aplicación

5. Especifique la raíz de contexto de la aplicación. Por ejemplo, una aplicación en https://mysite:9999/AppName tendrá una raíz de contexto de /AppName. La raíz de contexto debe comenzar con una barra diagonal (/), no debe terminar con una barra diagonal (/) y puede tener más de una capa de profundidad, por ejemplo, /Apps/MyApp.

6. Seleccione el host virtual que creó

   Nota:

   La combinación de host virtual y raíz de contexto debe ser única en PingAccess.

7. Seleccione la sesión web que ha creado

8. Seleccione el sitio que creó que contiene la aplicación

9. Seleccione la Asignación de identidad que ha creado

10. Seleccione Habilitado para habilitar el sitio al guardar

11. Seleccione Guardar.

Configuración de la política de autenticación PingFederate

Configura la política de autenticación de PingFederate para federarse con los múltiples IdPs proporcionados por los clientes de Azure AD B2C.

1. Cree un contrato para enlazar los atributos entre los IdP y el SP. Solo debe necesitar un contrato, a menos que el SP requiera un conjunto diferente de atributos de cada IdP. Para obtener más información, consulte Contratos de directiva de autenticación y centro de federación en la documentación de Ping Identity.

2. En cada IdP, cree una conexión de IdP entre el IdP y PingFederate, el centro de federación como SP.

3. En la ventana Target Session Mapping (Asignación de sesión de destino), agregue los contratos de directivas de autenticación aplicables a la conexión de IdP.

4. En la ventana Selectores , configure un selector de autenticación. Por ejemplo, vea una instancia del adaptador de identificador primero para asignar cada IdP a la conexión de IdP correspondiente en una política de autenticación.

5. Cree una conexión de SP entre PingFederate, el centro de federación como IdP y el SP.

6. Agregue el contrato de política de autenticación correspondiente a la conexión SP en la ventana Asignación de origen de autenticación .

7. Trabaje con cada IdP para conectarse a PingFederate, el centro de federación como SP.

8. Trabaje con el SP para conectarse a PingFederate, el centro de federación como IdP.

Pasos siguientes

Para obtener información adicional, consulte los siguientes artículos

• Directivas personalizadas de Azure AD B2C

• Introducción a las directivas personalizadas en Azure AD B2C