Inicio de sesión único

El inicio de sesión único (SSO) permite que un proveedor de identidad externo autentique a los usuarios de un espacio de trabajo Lerian. Access Manager resuelve el tenant del usuario, redirige el navegador al proveedor e intercambia el código de autorización del proveedor por tokens de acceso de Lerian. SSO aplica al inicio de sesión de usuarios. Las aplicaciones de máquina a máquina continúan usando credenciales de cliente.

​

Proveedores admitidos

---

Access Manager admite un proveedor SSO activo por tenant. Configurar otro proveedor reemplaza la configuración actual. Mientras el inicio de sesión con passkey está activado, Access Manager rechaza configurar un proveedor SSO.

​

Cómo funciona el inicio de sesión

---

1. Console solicita la dirección de correo electrónico del usuario.
2. Auth resuelve el tenant a partir de la dirección de correo electrónico, como se describe en Resolución del tenant. Después, devuelve el método de inicio de sesión disponible.
3. Console crea un desafío PKCE S256.
4. Auth redirige el navegador al proveedor de identidad configurado.
5. El proveedor autentica al usuario y devuelve un código de autorización a la URL de callback de Console.
6. Console envía el código, el estado y el verificador PKCE a Auth.
7. Auth verifica el flujo y la identidad de correo electrónico devuelta.
8. Auth devuelve tokens de acceso de Lerian, continúa con la verificación MFA o responde AUT-0019 cuando el usuario no tiene ningún método MFA y la organización exige uno.

Auth verifica que el correo electrónico devuelto por el proveedor pertenezca al mismo tenant que inició el flujo. Rechaza el inicio de sesión cuando falta el correo electrónico o este se resuelve a otro tenant.

​

Resolución del tenant

---

Cada tenant es una organización de Caradhras. SSO usa dos campos de esa organización:

• domain es el dominio de correo electrónico de los usuarios del tenant, como example.com. Auth rechaza el inicio de sesión SSO cuando el dominio del correo electrónico del usuario es distinto del domain del tenant.
• domainHome marca la única organización donde las personas de ese dominio reciben su cuenta cuando inician sesión con SSO por primera vez. Cada dominio tiene como máximo una organización principal.

Una persona con cuentas en varios tenants inicia sesión en su tenant predeterminado. Si la persona no tiene un tenant predeterminado, Auth elige uno. En Lerian Cloud, Lerian define estos campos por ti. En un despliegue BYOC, defínelos como se describe en Requisitos de despliegue de SSO. Un despliegue BYOC puede usar una organización fija, definida con PLUGIN_AUTH_SSO_STATIC_ORGANIZATION. Auth entonces no compara el dominio del correo electrónico con la organización. El descubrimiento no revela identificadores del tenant. Un correo electrónico desconocido recibe la misma respuesta general que un tenant sin SSO.

​

Validación de la configuración

---

Ejecuta la validación previa antes de guardar un proveedor. La validación previa no cambia la configuración del tenant. Verifica:

• los campos obligatorios.
• el descubrimiento de OpenID Connect cuando el proveedor usa una URL de emisor.
• la validación explícita de endpoints cuando la API proporciona URLs de autorización, token e información de usuario.
• las credenciales de cliente.
• la URL de callback.
• los endpoints resueltos de autorización, token e información de usuario.

Okta no siempre puede confirmar el registro del callback mediante la validación previa. Registra la URL de callback en Okta antes de activar el proveedor.

​

Próximos pasos

---