SP frente a SSO iniciada IdP

En este artículo se tratan los conceptos de SP y IdP SSO iniciada entre dos despliegues de federación, así como las diferencias entre estos dos flujos.

En este artículo también se explica el concepto de un estado de usuario o una URL de retorno compartida entre IdP y el SP durante el SSO de federación, que se denomina:

• RelayState para TARGET de SAML 2.0 para SAML 1.1 wctx para WS-Fed 1.1

• openid.return_to para OpenID 2.0 (la SSO de devolución)

• La URL puede contener un parámetro de consulta que representa el estado del usuario en el SP)

En este artículo se muestran ejemplos que utilizan el protocolo SAML 2.0, aunque lo mismo se aplica a otros protocolos.

Flujos SSO de Federación

Topología

Un despliegue típico de federación está formado por las siguientes entidades:

• Dominio de seguridad para el servidor IdP, donde el usuario tiene una cuenta y donde se produce la autenticación

• Un dominio de seguridad para el servidor SP con

  • Servidor de Federación de SP

  • Un servidor SSO (a veces, el servidor SSO y el servidor de federación SP son la misma entidad)

  • Agentes web SSO integrados con el servidor SSO, protegiendo los recursos y asegurándose de que el usuario está autenticado y autorizado para acceder a un recurso. De lo contrario, se puede producir un flujo de autenticación o un fallo de autorización

  • Recursos o aplicaciones web

  

  Descripción de la ilustración Federation_deployment_Screen.jpg

SSO iniciada por SP

Un flujo de SSO iniciado por SP es una operación de SSO de federación que se inició desde el dominio de seguridad de SP, mediante el servidor de federación de SP, la creación de una solicitud de autenticación de federación y el redireccionamiento del usuario a IdP con el mensaje y alguna cadena corta que representa el estado de la operación:

• La solicitud de autenticación de federación varía según el protocolo utilizado:

  • SAML 2.0: AuthnRequest

  • SAML 1.1: URL con un parámetro que representa el SP

  • WS-Fed: URL con un parámetro wtrealm que representa el SP y otros parámetros opcionales

  • OpenID 2.0: Solicitud de OpenID 2.0

• El estado de la operación (lo que el usuario estaba haciendo antes de que se iniciara la operación de SSO de federación) se transmite en el mensaje enviado a IdP con el usuario, no como estado completo, sino como puntero al estado en el almacenamiento de tiempo de ejecución del servidor de SP. Esta información se transmite de forma diferente según el protocolo:

  • SAML 2.0: parámetro RelayState

  • SAML 1.1: Parámetro TARGET

  • WS-Fed: parámetro wctx

  • OpenID 2.0: parámetro openid.return_to, que es una URL de SP a la que se redirige al usuario después de la autenticación en IdP, que genera el SP en tiempo de ejecución y, como tal, puede contener un parámetro de consulta que hace referencia a un estado operativo

Nota sobre el estado operativo: por lo general, el estado compartido en el mensaje no debe ser demasiado largo, ya que podría romper los flujos de redirección con la longitud de la URL de redirección que supera la longitud máxima que los exploradores pueden manejar para las URL. Por lo tanto, siempre es preferible que durante el inicio de sesión único iniciado por el SP tenga el SP.

• Almacenar el estado operativo en el almacenamiento de memoria/base de datos en el SP

• Envíe como RelayState/TARGET/wctx un puntero al estado operativo

Hay dos formas de disparar un flujo de SSO iniciado por SP:

• El usuario solicita acceso a un recurso, que inicia un flujo de SSO de federación. Una vez realizada la operación de SSO de federación, se redirigirá al usuario al recurso solicitado en primer lugar.

• O el usuario accede directamente a un servicio en el servidor del SP para iniciar específicamente un flujo de SSO de federación con un IdP remoto. En este caso, el usuario suele proporcionar la dirección URL a la que se debe redirigir después de realizar la operación SSO de federación

Acceso a un recurso

Este es el flujo más común para las operaciones de SSO de federación, donde el usuario intenta acceder a un recurso protegido y el sistema SSO en tiempo de ejecución determina que el usuario debe autenticarse mediante SSO de federación.

Los casos de uso en los que se utiliza este flujo pueden ser:

• El usuario hace clic en un enlace de cualquier página que haga referencia al recurso protegido

• El usuario hace clic en un enlace de una página de portal que hace referencia al recurso protegido

• El usuario tiene un marcador para el recurso protegido

El flujo incluye los siguientes pasos:

1. El explorador del usuario solicita acceso a un recurso protegido

2. El agente web SSO intercepta la llamada, determina que el usuario debe autenticarse y emite un redireccionamiento al explorador del usuario

3. El explorador del usuario accede al servidor SSO, redirigido por el agente web SSO

4. El servidor SSO determina que el usuario se debe autenticar mediante SSO de federación, selecciona IdP, crea un mensaje AuthnRequest de SAML 2.0, guarda el estado operativo en el almacén del servidor SSO y redirige el explorador del usuario a IdP con el mensaje SAML y una cadena que hace referencia al estado operativo en el SP

5. El explorador del usuario accede al servicio IdP SAML 2.0 con el mensaje AuthnRequest.

Descripción de la ilustración Accessing_Resources_Screen.jpg

Una vez que IdP recibe el mensaje AuthnRequest de SAML 2.0, el servidor determina si el usuario debe ser desafiado (aún no autenticado, la sesión ha sufrido un timeout...). Después de la posible identificación del usuario, se reanuda el flujo de SSO de federación.

1. IdP crea una respuesta SSO con una afirmación SAML 2.0 que contiene información de usuario y datos de autenticación, y redirige el explorador del usuario al SP con el mensaje y el parámetro RelayState

2. El explorador del usuario presenta la respuesta de SSO al servidor del SP

3. El SP valida la afirmación de SAML 2.0 y crea una sesión de SSO para el usuario. A continuación, el servidor SSO redirige el explorador del usuario al recurso solicitado originalmente.

4. El explorador del usuario solicita acceso al recurso. Esta vez, el agente web de SSO otorga acceso al recurso

5. La aplicación web devuelve una respuesta al explorador del usuario

Descripción de la ilustración Accessing_Resources_Response_Screen.jpg

Como se ha mencionado anteriormente, este flujo es el más utilizado, ya que el servidor SSO de federación solo lo dispara en tiempo de ejecución, sin que sea necesario que ningún otro componente del dominio de seguridad de SP tenga en cuenta la federación.

Llamada a un Servicio de SP de Federación

Este flujo no se utiliza ampliamente, ya que implica que el SSO de federación se iniciará en el SP accediendo a un servicio en el servidor del SP y haciendo caso omiso de cualquier sesión válida existente que el usuario ya pueda tener. Como tal, se debe evitar, ya que tiene un impacto en el rendimiento en:

• Los servidores como SSO de federación son caros (XML para algunos protocolos, firmas digitales para proteger los mensajes y comunicaciones entre servidores)

• La experiencia del usuario como explorador se redirigirá a través de diferentes dominios, lo que genera un retraso antes de que el usuario pueda acceder al recurso protegido de destino.

Los casos de uso en los que se utiliza este flujo pueden ser:

• El usuario hace clic en un enlace de cualquier página que haga referencia al recurso protegido (normal)

• El usuario hace clic en un enlace de una página de portal que hace referencia al recurso protegido

Los casos de uso en los que se utiliza este flujo incluyen los siguientes pasos:

1. El explorador del usuario accede al SP para iniciar un flujo de SSO de federación especificando opcionalmente

   1. URL a la que se debe redirigir el explorador del usuario después de terminar el SSO de federación

   2. IdP que se va a utilizar

2. El servidor SSO selecciona IdP si no se proporciona y selecciona la URL de devolución por defecto si no se proporciona, crea un mensaje AuthnRequest de SAML 2.0, guarda el estado operativo en el almacén del servidor SSO y redirige el explorador del usuario a IdP con el mensaje SAML y una cadena que hace referencia al estado operativo en el SP

3. El explorador del usuario accede al servicio IdP SAML 2.0 con el mensaje AuthnRequest.

Descripción de la ilustración IdP_Service_with_AuthnRequest_Screen.jpg

Una vez que IdP recibe el mensaje AuthnRequest de SAML 2.0, el servidor determina si el usuario debe ser desafiado (aún no autenticado, la sesión ha sufrido un timeout...). Después de la posible identificación del usuario, se reanuda el flujo de SSO de federación:

1. IdP crea una respuesta SSO con una afirmación SAML 2.0 que contiene información de usuario y datos de autenticación, y redirige el explorador del usuario al SP con el mensaje y el parámetro RelayState

2. El explorador del usuario presenta la respuesta de SSO al servidor del SP

3. El SP valida la afirmación de SAML 2.0 y crea una sesión de SSO para el usuario. A continuación, el servidor SSO redirige el explorador del usuario al recurso solicitado originalmente.

4. El explorador del usuario solicita acceso al recurso. Esta vez, el agente web de SSO otorga acceso al recurso

5. La aplicación web devuelve una respuesta al explorador del usuario

Descripción de la ilustración IdP_Service_with_Response_Screen.jpg

Este flujo rara vez se debe utilizar, ya que el SSO de federación se dispara de forma estática, incluso si el usuario ya tiene una sesión de SSO válida. Además, implica que algunos componentes del dominio de seguridad del SP deben conocer el servicio del SP.

IdP SSO iniciada

Un flujo de SSO iniciado por IdP es una operación de SSO de federación que se ha iniciado desde el dominio de seguridad IdP, mediante el servidor de federación IdP creando una respuesta de SSO de federación y redirigiendo al usuario al SP con el mensaje de respuesta y un estado operativo opcional:

• La respuesta SSO de federación varía según el protocolo utilizado:

  • SAML 2.0: SAMLResponse con afirmación

  • SAML 1.1: Respuesta con Afirmación

  • WS-Fed: Respuesta con Afirmación

  • OpenID 2.0: respuesta a OpenID 2.0

• El estado de operación opcional de este flujo transmite la URL a la que se debe redirigir al usuario una vez que se haya completado el SSO de federación en el SP. Si falta, el SP debe determinar a dónde se debe redirigir al usuario. Esta información se transmite de forma diferente según el protocolo:

  • SAML 2.0: parámetro RelayState

  • SAML 1.1: parámetro TARGET

  • WS-Fed: Parámetro wctx OpenID 2.0: este protocolo no soporta el flujo de SSO iniciado por IdP.

Como se indica en la sección anterior, el estado compartido en el mensaje no debe ser demasiado largo, ya que podría romper los flujos de redirección con la longitud de la URL de redirección que supera la longitud máxima que los exploradores pueden manejar para las URL.

Este flujo se utiliza normalmente cuando los usuarios de IdP necesitan acceder a recursos alojados por un SP, pero no es el mejor enfoque para SSO de federación, ya que no tiene en cuenta ninguna sesión válida existente en el SP que el usuario ya podría tener. Como tal, se debe evitar, ya que tiene un impacto en el rendimiento en:

• Los servidores como SSO de federación son caros (XML para algunos protocolos, firmas digitales para proteger los mensajes y comunicaciones entre servidores)

• La experiencia del usuario como explorador se redirigirá a través de diferentes dominios, lo que genera un retraso antes de que el usuario pueda acceder al recurso protegido de destino.

Los casos de uso en los que se utiliza este flujo pueden ser:

• El usuario hace clic en un enlace de una página del portal IdP que hace referencia al recurso protegido en el SP.

Los casos de uso en los que se utiliza este flujo incluyen los siguientes pasos:

1. El explorador del usuario accede a IdP para iniciar un flujo de SSO de federación especificando

   1. El SP que se va a utilizar

   2. Opcionalmente, la dirección URL a la que se debe redirigir el explorador del usuario después de terminar el SSO de federación

2. Después de haber identificado al usuario, IdP crea una respuesta SSO con una afirmación SAML 2.0 que contiene información de usuario y datos de autenticación, y redirige el explorador del usuario al SP con el mensaje y el parámetro RelayState

3. El explorador del usuario presenta la respuesta de SSO al servidor del SP

4. El SP valida la afirmación de SAML 2.0 y crea una sesión de SSO para el usuario. A continuación, el servidor SSO redirige el explorador del usuario al recurso solicitado originalmente.

5. El explorador del usuario solicita acceso al recurso. Esta vez, el agente web de SSO otorga acceso al recurso

6. La aplicación web devuelve una respuesta al explorador del usuario

Descripción de la ilustración SSO_Response_Screen.jpg

Conclusión

Como se ve en los distintos flujos, el mejor enfoque en un despliegue de federación es que el servidor SSO de federación lo dispare en tiempo de ejecución, cuando lo considere necesario el servidor SSO. Los otros casos tienen un enfoque estático y siempre ejercen un flujo de SSO de federación, incluso si no es necesario (si el usuario ya tiene una sesión válida, por ejemplo) y realizan un impacto innecesario en las operaciones de federación:

• Rendimiento de los servidores (interacciones LDAP/RDBMS, CPU, etc.)

• Tiempo de respuesta del usuario, en función del tiempo que se tarda en realizar una operación SSO de federación con los redireccionamientos implicados.

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

SP vs IdP Initiated SSO

F60244-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.