Proxy de Federación en OAM y IdP

En este artículo se explica el concepto de proxy de federación y cómo IdP se puede configurar fácilmente para convertirse en un SP y delegar la autenticación a otro IdP remoto en lugar de autenticar al usuario localmente.

El proxy de federación se utiliza normalmente cuando un hub de federación actúa como:

Una IdP para partners de SP, donde IdP agrega confianza de federación entre esos SP y ellos mismos
Un SP con socios IdP remotos

Este enfoque tiene la ventaja de:

Reducción de la sobrecarga de gestión de confianza
Cada nuevo partner IdP agregado al hub de federación estará disponible automáticamente para todos los partners de SP integrados con el hub de federación.
No será necesario definir cada nuevo partner de SP agregado al hub de federación en los partners IdP
Proporcionar un modelo de confianza de federación en capas, donde el hub de federación oculta el despliegue de federación a los partners IdP

Modelo de confianza directa

En este modelo, los distintos servidores de Federation confían directamente entre sí y no hay entidades intermedias que actúen como proxy.

Este modelo tiene la ventaja de reducir la complejidad de los flujos de federación, porque solo dos servidores están implicados en la operación de SSO, pero a veces tiene el inconveniente de crear una enorme sobrecarga de gestión que los partners podrían no estar de acuerdo.

Tomemos un ejemplo de una empresa global llamada ACME Corp, que tiene oficinas en todo el mundo. La estructura de la compañía está formada por tres organizaciones principales que representan una región diferente del mundo, y cada organización está a cargo de su dominio de seguridad:

Norteamericano y sudamericano
Europeo
Asia-África Pacífico

Cada organización tiene su propio dominio de seguridad, lo que significa:

Un conjunto de recursos
Un servidor SSO
Un servidor de federación Las entidades de una organización son independientes de las de otra organización. Como tal, la autenticación en un dominio no le otorgará acceso a los recursos de otro dominio hasta que se haya realizado la autenticación en ese otro dominio.

Ahora, digamos que ACME Corp quiere tener un acuerdo de federación con algunos proveedores de servicios, algunos de los cuales son proveedores, otros son servicios comprados por ACME Corp, como un servicio de conferencia telefónica, así como un servicio Webex.

Para establecer la federación entre las distintas organizaciones de ACME Corp y los SP, el servidor de federación de cada organización debe establecer la confianza con cada SP remoto:

El número de establecimientos de confianza debe ser alto
Los socios del SP podrían negarse a este tipo de establecimiento de confianza, dado el elevado número de acuerdos de federación implicados para un único cliente.

Este diagrama representa todos los acuerdos que deberían establecerse:

Descripción de la ilustración Direct_Trust_Model.jpg

Este enfoque se suele evitar, ya que publica al partner la complejidad interna de la infraestructura de ACME Corp.

Se han definido SSO de federación y SAML para permitir que dos dominios de seguridad distintos realicen SSO entre dominios de forma que un partner no necesite saber sobre la implantación y el despliegue de seguridad del otro partner. En este caso, se hace evidente que esta promesa se ha incumplido y que la complejidad de las opciones de seguridad de ACME Corp está afectando a los partners de SP.

Modelo de confianza con corretaje

En este modelo, existe el concepto de proxy de federación en el que se deben utilizar algunas entidades para actuar como proxies/SP para realizar operaciones de SSO de federación en nombre de otros SP.

Si volvemos a tomar nuestro ejemplo de ACME Corp, el enfoque correcto para implementar SSO de federación con otros partners de SP es a través de un modelo de confianza con corretaje o proxy de federación, donde:

Se instalará un nuevo servidor en ACME Corp que actúa como hub de federación
El hub de federación actúa como proveedor de servicios para el IdPs interno de ACME Corp.
El hub de federación actúa como IdP para los SP externos (proveedores, llamada en conferencia y webex)
Durante una operación SSO de federación, en lugar de desafiar al usuario directamente, el hub actúa como un SP y dispara una operación SSO de federación con un IdP interno remoto.

Este enfoque está más en línea con la filosofía de federación/SAML, donde los partners externos desconocen la infraestructura de seguridad y los componentes de ACME Corp, e interactúan solo con un único IdP.

Esta solución también resuelve los altos gastos generales de gestión en los que el número de acuerdos era particularmente elevado y hacía que las actualizaciones del acuerdo fueran un proceso largo. Con este enfoque:

Los acuerdos de federación se establecen entre el hub y el IdPs interno, y entre el hub y los SP externos
La agregación de una IdP interna será invisible para los SP externos
La adición de un SP externo será invisible para el IdPs interno.
La actualización del acuerdo de federación (por ejemplo, para la renovación de claves) será una operación única en lugar de repetirse varias veces

Este diagrama representa los acuerdos de federación necesarios en un modelo de confianza con corretaje (o proxy de federación):

Descripción de la ilustración Brokered_Trust_Model.jpg

Proxy de Federación en OAM

El objetivo de un proxy de federación es convertir IdP en un SP para que, al recibir una solicitud de SSO desde un primer SP remoto, en lugar de desafiar al usuario localmente, IdP se convierta en un SP y dispare una nueva operación de SSO de federación con un segundo IdP remoto.

Una vez finalizada correctamente la segunda operación de SSO de federación, el proxy IdP habrá identificado al usuario y podrá crear una respuesta de SSO para el SP original.

OAM soporta el proxy de federación ahora para todos los protocolos:

SAML 2.0, SAML 1.1 y OpenID 2.0
El protocolo entre el SP original y IdP es el mismo que el utilizado entre OAM/SP y el segundo IdP remoto
El protocolo entre el SP original y IdP es diferente del que se utiliza entre OAM/SP y el segundo IdP remoto

Por lo tanto, un SP podría realizar SSO de federación con IdP a través de SAML 1.1, y IdP se convierte en SP y SSO de federación con un segundo IdP remoto a través de SAML 2.0. El SP original no necesita conocer el protocolo utilizado entre OAM/SP y el segundo IdP o incluso que se haya realizado una segunda operación de SSO de federación.

En un proxy de federación Ahora, IdP se puede configurar para "reenviar" el método de autenticación de federación especificado en el segundo SSO de federación al SP original.

Configuración de OAM para Proxy de Federación

Como se ha explicado anteriormente, IdP aprovecha OAM para la autenticación de usuario: cada vez que se realiza una operación de SSO de federación, IdP llama a OAM especificando un esquema de autenticación, para asegurarse de que el usuario está autenticado correctamente y, si es necesario, lo desafía.

Como sabe, OAM define esquemas específicos vinculados a OAM/SP: si un usuario no autenticado solicita acceso a un recurso protegido por FederationScheme (o esquema que utiliza un módulo de autenticación similar a FederationPlugin), OAM llama a OAM/SP que dispara una operación SSO de federación con un IdP remoto.

Por lo tanto, para que IdP realice un proxy de federación ahora, en lugar de que IdP llame a OAM con un esquema de autenticación local, debe tener IdP llamado a OAM con FederationScheme. Desde allí:

OAM llama a OAM/SP y que dispara un nuevo SSO de federación ahora con un segundo IdP remoto
El segundo IdP remoto autentica al usuario si es necesario, emite una respuesta SSO
OAM/SP valida la respuesta de SSO, cree una sesión de OAM
OAM redirige al usuario a IdP
IdP crea una respuesta SSO y redirige al usuario al SP original con esa respuesta

Comando WLST

Para configurar IdP para utilizar SSO de federación para autenticar un usuario en lugar de un mecanismo de autenticación local, ejecute uno de los siguientes comandos:

setIdPDefaultScheme() para definir el esquema por defecto global como un esquema de federación
setSPPartnerProfileDefaultScheme() para definir el esquema por defecto en un perfil de socio de SP
setSPPartnerDefaultScheme() para definir el esquema por defecto en un socio de SP

Consulte el artículo sobre autenticación en IdP para obtener más información sobre cómo configurar OAM para la autenticación. En este ejemplo, configure IdP de forma global para utilizar el SSO de federación como mecanismo de autenticación por defecto:

Introduzca el entorno WLST ejecutando: $IAM_ORACLE_HOME/common/bin/wlst.sh.
Conéctese al servidor de administración de WLS: connect().
Navegue a la rama Domain Runtime: domainRuntime().
Ejecute el comando setIdPDefaultScheme(): setIdPDefaultScheme("FederationScheme").
Salga del entorno WLST: exit().

Con este cambio, se utiliza FederationScheme para autenticar usuarios.

Se pueden utilizar otros esquemas de federación para autenticar al usuario; OAM se configura en el nivel global (todos los usuarios de todos los SP se autentican mediante ese esquema de federación) o en el nivel de partner de SP (todos los usuarios que realizan SSO de federación con ese SP específico se autentican mediante ese esquema de federación). Recuerde que puede crear un esquema de federación para un IdP específico, ya sea mediante el comando WLST createAuthnSchemeAndModule de OAM o mediante la sección Editar Partner IdP de la Consola de Administración de OAM.

Determinación del segundo IdP que se va a utilizar

Cuando se utiliza un esquema de federación para la autenticación en OAM, OAM/SP deberá determinar qué IdP utilizar para la operación SSO de federación:

Si el esquema se ha creado a partir de una entrada de partner IdP, indica a OAM/SP que realice la SSO de federación con esa IdP
Si el esquema es FederationScheme, OAM/SP primero evalúa si está configurado para utilizar un servicio de detección IdP
Si está configurado para un servicio de detección IdP, OAM/SP redirige al usuario a ese servicio para seleccionar un IdP
De lo contrario, OAM/SP utiliza el SSO por defecto IdP

Para definir un partner IdP como el SSO por defecto IdP:

Vaya al partner IdP en la consola de administración de OAM y active la casilla de control Socio de proveedor de identidad por defecto
O utilice el comando WLST setDefaultSSOIdPPartner() de OAM especificando el nombre del partner IdP

Proxion de Métodos de Autenticación de Federación

Como se explica en un artículo anterior, cuando IdP crea una afirmación, asigna el esquema OAM local utilizado para autenticar el usuario a un método de autenticación de federación.

En el caso de un proxy SSO de federación Ahora, esto significa que se asigna FederationScheme a un método de autenticación de federación. Por ejemplo, si el esquema se debe asignar a urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport para SAML 2.0, el administrador utiliza un comando similar a:

Para crear la asignación en un nivel de perfil de socio de SP: addSPPartnerProfileAuthnMethod("saml20-sppartner-profile","urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "FederationScheme")
Para crear la asignación en el nivel de socio de SP: addSPPartnerAuthnMethod("AcmeSP","urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ", "FederationScheme")

En algunos casos, puede ser preferible reenviar el método de autenticación de federación recibido del segundo IdP en lugar de asignar localmente el esquema de federación a un método de autenticación de federación.

Configurar IdP para reenviar los métodos de autenticación de federación en un proxy SSO de federación.

Ahora, utilice el comando useProxiedFedAuthnMethod():

Introduzca el entorno WLST ejecutando: $IAM_ORACLE_HOME/common/bin/wlst.sh.
Conéctese al servidor de administración de WLS: connect().
Navegue a la rama Domain Runtime: domainRuntime().
Ejecute el comando useProxiedFedAuthnMethod(): useProxiedFedAuthnMethod(enabled="true/false",authnSchemeToAdd="SCHEME", authnSchemeToRemove="SCHEME").

El parámetro activado indica si se debe configurar IdP para reenviar los métodos de autenticación de federación en un proxy SSO de federación ahora
El parámetro authnSchemeToAdd indica qué esquema de autenticación de OAM es un esquema de federación: permite a IdP determinar si utilizar o no el método de autenticación de federación almacenado en caché según el esquema de autenticación de la sesión del usuario
El parámetro authnSchemeToRemove elimina un esquema de autenticación de OAM de la lista de esquemas marcados como esquemas de federación para los que IdP debe utilizar el método de autenticación de federación de proxy
Un ejemplo es: useProxiedFedAuthnMethod(enabled="true", authnSchemeToAdd="FederationScheme")

Salga del entorno WLST: exit().

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.

Título e Información de Copyright

Federation Proxy in OAM and IdP

F60446-01

September 2022