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

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

Muchos sitios de comercio electrónico y aplicaciones web expuestos a Internet se implementan detrás de sistemas proxy o un sistema de proxy inverso. Estos sistemas proxy autentican previamente, aplican la directiva y enrutan el tráfico. Entre los casos de uso típicos están la protección de aplicaciones web frente al tráfico web entrante y proporcionar una administración de sesiones uniforme en implementaciones de servidor distribuidas.

En general, esta configuración incluye una capa de traducción de autenticación que externaliza la autenticación desde la aplicación web. Los proxies inversos proporcionan el contexto del usuario autenticado a las aplicaciones web, como un valor de encabezado en formato claro o 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). sino que el proxy proporciona el contexto de autenticación y mantiene la sesión con el agente de usuario final, como el explorador o la aplicación nativa. En tanto que servicio de tipo "man in the middle", los servidores proxy proporcionan un control de sesión bastante significativo. El servicio proxy es eficaz y escalable, y no un cuello de botella para las aplicaciones detrás del servicio proxy. Este diagrama es un flujo de comunicaciones e implementación de proxy inverso.

Modernización

Si busca modernizar una plataforma de identidad en este tipo de configuraciones, hay aspectos que pueden preocupar a los clientes:

• Los esfuerzos de modernización de las aplicaciones están desvinculados 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:
  • Fomentan la coherencia de la experiencia de usuario final.
  • Proporcionan una sola experiencia de inicio de sesión único en todas las aplicaciones.

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

Entorno compartido

Una solución técnicamente viable que también resulta rentable es configurar el sistema proxy inverso para que use el sistema de identidad modernizado y delegue la autenticación.
Los proxies admiten los protocolos de autenticación modernos y usan la autenticación basada en el redireccionamiento (pasiva) que envía al usuario al nuevo proveedor de identidades (IdP).

Azure AD B2C como proveedor de identidades

En Azure AD B2C se definen las directivas en las que se basan los comportamientos y las experiencias de los usuario (lo que se conoce como "recorridos del 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.
Azure AD B2C se puede configurar para que haya un emisor común en todas las directivas o un emisor exclusivo para cada directiva. Cada aplicación puede apuntar a directivas realizando una solicitud de autenticación nativa del protocolo, lo que fomenta comportamientos de usuario como el inicio de sesión, el registro y las ediciones de perfil. El diagrama muestra los flujos de trabajo de aplicación OIDC y SAML.

Este escenario puede dificultar 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 experiencia de 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.

PingAccess como proxy inverso

PingAccess se puede implementar 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 en un proveedor de autenticación ascendente. Puede configurar un IdP ascendente con este propósito en el servidor de PingAccess. Consulte el diagrama siguiente:

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

PingFederate como proxy de federación

PingFederate se puede configurar como un proveedor de autenticación o como un proxy para IdP ascendentes. Consulte el diagrama siguiente:

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

Requisitos previos

Para empezar, necesitará lo siguiente:

• Una suscripción de Azure
  • Si no tiene una, obtenga una cuenta gratuita de Azure.
• Un inquilino de Azure AD B2C vinculado a la suscripción de Azure
• PingAccess y PingFederate implementados en contenedores Docker o en máquinas virtuales 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 de AuthN heredada o basada en encabezados: se comunica con el servidor de PingAccess y desde este.
• Aplicación de usuario de confianza de SAML: accede al tráfico del explorador desde el cliente. Accede a los metadatos de federación de 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: accede 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 usar los flujos de usuario básicos o las 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 mediante las propiedades de las directivas de flujo de usuario.

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

Configuración de PingAccess y PingFederate

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

Configuración de PingFederate como proveedor de tokens

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

Para obtener más información, consulte Configurar PingFederate como proveedor de tokens para PingAccess en la documentación de Ping Identity.

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

Siga estas instrucciones para crear una aplicación de PingAccess para la autenticación basada en encabezados de la aplicación web de destino.

Creación de un host virtual

Importante

Cree un host virtual para cada aplicación. Para obtener más información, consulte ¿Qué puedo configurar con PingAccess? en la documentación de Ping Identity.

Para crear un host virtual:

1. Vaya a Configuración>Acceso>Virtual Hosts (Hosts virtuales).
2. Seleccione Add Virtual Host (Agregar host virtual).
3. En Host, escriba la parte del FQDN de la dirección URL de la aplicación.
4. En el campo Puerto, escriba 443.
5. Seleccione Guardar.

Creación de una sesión web

Para crear una sesión web:

1. Vaya a Configuración>Acceso>Web Sessions (Sesiones web).
2. Seleccione Add Web Session (Agregar sesión web).
3. Escriba un Nombre para la sesión web.
4. Seleccione el valor que quiera en Cookie Type (Tipo de cookie), ya sea Signed JWT (JWT firmado) o Encrypted JWT (JWT cifrado).
5. Escriba un valor único en Audiencia.
6. En Id. de cliente, escriba el Microsoft Entra ID de aplicación.
7. En Secreto de cliente, escriba la clave que generó para la aplicación en Microsoft Entra ID.
8. (Opcional) Cree y use notificaciones personalizadas con Microsoft Graph API: seleccione Avanzado. Anule la selección de Request Profile (Perfil de solicitud) y de Refresh User Attributes (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.

Creación de una asignación 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 una asignación 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 Type of Header Identity Mapping (Tipo de asignación de identidad de encabezado).
5. En la tabla Attribute-Mapping (Asignación y atributos), especifique las asignaciones necesarias. Por ejemplo,

Nombre del atributo	Nombre de encabezado
"upn"	x-userprincipalname
"email"	x-email
"oid"	x-oid
"scp"	x-scope
"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 a Principal>Sitios.
2. Seleccione Agregar sitio.
3. Escriba el Nombre del sitio.
4. Especifique el Destino del sitio. El destino es el par de nombre de host y puerto del servidor que hospeda la aplicación. No escriba la ruta de acceso de la aplicación en este campo. Por ejemplo, una aplicación en 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 Trust Any (Confiar en cualquiera).
7. Seleccione Guardar.

Crear una aplicación

Para crear una aplicación de PingAccess en cada aplicación de Azure que quiera proteger:

1. Vaya a Principal>Aplicaciones.

2. Seleccione Agregar aplicación.

3. Escriba un Nombrepara la aplicación.

4. También puede escribir una Descripción para la aplicación.

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

6. Seleccione el Host virtual que ha creado.

   Nota:

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

7. Seleccione la Sesión web que ha creado.

8. Seleccione el Sitio que ha creado y 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 directiva de autenticación de PingFederate

Configure la directiva de autenticación de PingFederate para federar en los distintos IdP proporcionados por los inquilinos de Azure AD B2C.

1. Cree un contrato para enlazar los atributos entre los IdP y el SP. Solo debería necesitar un contrato, a menos que el SP requiera otro conjunto 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 Identifier First Adapter (Primer adaptador del identificador) para asignar cada IdP a la conexión de IdP correspondiente en una directiva 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 directiva de autenticación correspondiente a la conexión de SP en la ventana Authentication Source Mapping (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 más información, consulte los artículos siguientes:

• Directivas personalizadas de Azure AD B2C

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