Configurar el inicio de sesión único (SSO) iniciado desde el Proveedor de identidad SAML

Describe cómo configurar el inicio de sesión único (SSO) iniciado desde el Proveedor de identidad SAML.

Muchas instrucciones para configurar una federación de SAML comienzan con inicio de sesión único (SSO) iniciado por el proveedor de servicios. El proveedor de servicios redirige al usuario al proveedor de identidad (IdP) para su autenticación. Este proceso se utiliza habitualmente en escenarios orientados al consumidor.

Sin embargo, en escenarios empresariales, en ocasiones también es habitual que el SSO lo inicie el IdP en lugar del proveedor de servicios. Por ejemplo, una empresa puede configurar un portal para asegurarse de que los usuarios accedan a la aplicación correcta después de iniciar sesión en el portal.

​

Riesgos y consideraciones

Los flujos iniciados por el IdP conllevan un riesgo de seguridad y, por lo tanto, no se recomiendan. Se recomienda usar flujos iniciados por el SP siempre que sea posible.

Asegúrese de comprender los riesgos antes de habilitar el SSO iniciado por el IdP. En este escenario, Auth0 recibe la respuesta no solicitada del IdP y la aplicación recibe la respuesta no solicitada de Auth0. Ninguna de las dos entidades puede verificar que el usuario haya iniciado el flujo. Por ello, habilitar este flujo abre la posibilidad de un ataque CSRF de inicio de sesión, en el que un atacante puede engañar a un usuario legítimo para que, sin saberlo, inicie sesión en la aplicación con la identidad del atacante.

​

Flujo iniciado por el IdP de OpenID Connect

OpenID Connect (OIDC) no admite el concepto de flujo iniciado por IdP. Por lo tanto, aunque Auth0 ofrece la posibilidad de transformar un flujo SAML iniciado por IdP (desde una conexión SAML) en una respuesta OIDC para una aplicación, cualquier aplicación que implemente correctamente el protocolo OIDC/OAuth2 rechazará una respuesta no solicitada.

Al usar aplicaciones OIDC, la mejor opción es que la aplicación cree un endpoint de inicio de sesión. El único propósito de este endpoint es iniciar la redirección de vuelta al IdP (su inquilino de Auth0).

Si utiliza varios IdP, asegúrese de que el endpoint de inicio de sesión sea específico para el proveedor de identidad o de que pueda aceptar un parámetro para identificar qué IdP inicia el flujo.

Como alternativa, puede hacer que los usuarios inicien el flujo de inicio de sesión desde la aplicación.

​

URL de retorno

Al usar SSO iniciado por el IdP, asegúrese de incluir el parámetro connection en la URL de retorno:

Si usa la funcionalidad Organizaciones, también puede incluir opcionalmente un parámetro organization que contenga el ID de la organización deseada:

Para que los usuarios puedan iniciar sesión correctamente con este método, la conexión debe estar habilitada para la Organización. Además, debe configurar la asignación automática de membresía para la conexión habilitada o asegurarse de que los usuarios pertenezcan a la Organización.

​

Lock/Auth0.js

Si su aplicación es una aplicación de una sola página que usa Lock o Auth0.js para procesar los resultados de la autenticación, debe indicar explícitamente que desea permitir flujos iniciados por el IdP y, por lo tanto, exponer la aplicación a posibles ataques CSRF de inicio de sesión.

Si usa Auth0.js, debe actualizar webAuth.parseHash de la biblioteca y establecer la marca __enableIdPInitiatedLogin en true.

var data = webAuth.parseHash(
      {
        ...
        __enableIdPInitiatedLogin: true
        ...
      }

Si usas Lock, puedes incluir la marca mediante el parámetro options que se envía al constructor.

const lock = new Auth0Lock(clientID, domain, options)

Esta es la marca en sí:

var options = { _enableIdPInitiatedLogin: true };

Ten en cuenta que la marca enableIdPInitiatedLogin va precedida de un guion bajo cuando se usa con Lock y de dos guiones bajos cuando se usa con la biblioteca auth0.js.

​

Configurar el SSO iniciado por IdP

1. Vaya a Dashboard > Authentication > Enterprise y elija SAMLP Identity Provider.

2. En Settings puede ver la configuración del SSO iniciado por IdP.

   

• Comportamiento del SSO iniciado por IdP: Esta opción le permite habilitar inicios de sesión iniciados por IdP para la conexión SAML. Seleccione Accept Requests y complete todos los campos obligatorios.
• Aplicación predeterminada: Cuando el inicio de sesión iniciado por IdP se completa correctamente, esta es la aplicación a la que se redirige a los usuarios. Esta configuración muestra las aplicaciones disponibles habilitadas para esta conexión. En la lista desplegable, seleccione la aplicación con la que desea que los usuarios inicien sesión mediante IdP. Solo se puede seleccionar una aplicación para un inicio de sesión iniciado por IdP por conexión SAML.
• Protocolo de respuesta: Este es el protocolo que se usa para conectar la Aplicación predeterminada seleccionada. Lo más común es que las aplicaciones estén configuradas con el protocolo OpenID Connect (consulte arriba). Sin embargo, si ha configurado un complemento SAML2 Web App para su aplicación y quiere enrutar la aserción SAML, deberá seleccionar SAML. Una vez que se haya enviado una aserción SAML válida a la URL de postback, Auth0 envía una respuesta de inicio de sesión a la primera URL de callback permitida de la aplicación predeterminada configurada mediante el protocolo de respuesta elegido, que puede modificarse con el campo de cadena de consulta para especificar un redirect_uri si usa OIDC.
  • Si la URL de callback configurada para la aplicación incluye un marcador de posición de Multiple Custom Domains (MCD), el sistema lo completa dinámicamente con el valor de metadatos que corresponde al dominio personalizado de la URL de postback que recibió la solicitud inicial del IdP. Para obtener más información, consulte Multiple Custom Domains.
• Cadena de consulta: Las opciones de la cadena de consulta ayudan a personalizar el comportamiento cuando se usa el protocolo OpenID Connect. Puede establecer varias opciones, de forma similar a configurar parámetros con una cadena de consulta. Puede configurar lo siguiente:

Configuración	Descripción
redirect_uri	Cuando se completa el inicio de sesión iniciado por IdP, la solicitud se redirige a la primera URL incluida en Allowed Callback URLs de la aplicación. Sin embargo, si establece un redirect_uri, el IdP redirigirá a esta URL. Esto aporta flexibilidad en casos como cuando tiene un esquema de subdominios con un comodín y solo quiere redirigir a un subdominio específico.
scope	Defina los alcances del ID Token enviado. Puede establecer varios alcances.
response_type	Establezca token para el flujo Implicit Grant Flow para SPA. Puede establecer code para el flujo Authorization Code Grant Flow para aplicaciones web tradicionales.

En un flujo iniciado por IdP, los servidores de Auth0 eliminan los alcances de un token si la URL de callback es un dominio no verificado. Auth0 define solo localhost y 127.0.0.1 como dominios no verificados. Si usa cualquiera de ellos como URL de callback, los tokens del endpoint /userinfo devolverán una respuesta vacía. Para obtener una respuesta de token con los alcances solicitados, use un dominio verificado.

Ejemplo de cadena de consulta: redirect_uri=https://jwt.io&scope=openid email&response_type=token

​

Lista desplegable de aplicaciones limitada a 100

Si desea seleccionar una aplicación como la Aplicación predeterminada en el SSO iniciado por el IdP y la aplicación no se encuentra entre las primeras 100 aplicaciones que aparecen en la lista desplegable de su inquilino, debe usar la Management API para seleccionar esa aplicación. Debe realizar una solicitud PATCH:

{
"options": {
"signInEndpoint": "yourIdpSignInUrl",
"idpinitiated": {
"client_id": "yourClientId",
"client_protocol": "saml",
"client_authorizequery": ""
},
"signingCert": "[copied-from-GET]"
}
}

​

Más información

• Trabajar con certificados y claves como cadenas de texto