Skip to main content
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.
Este contrato SSO usa OAuth 2.0 y OpenID Connect. No configura un proveedor SAML.

​
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 del dominio del correo electrónico mediante una etiqueta de la organización con el prefijo domain:, como domain:example.com, o usa la organización fija configurada por PLUGIN_AUTH_SSO_STATIC_ORGANIZATION en un despliegue BYOC de un solo 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 o continúa con la verificación MFA.
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

Un despliegue BYOC de tenant único puede usar una organización fija. No combines SSO de organización fija con multi-tenancy. El descubrimiento no revela identificadores del tenant. Un correo electrónico desconocido recibe la misma respuesta general que un tenant sin SSO.

​
Política de inicio de sesión con contraseña

Un tenant puede permitir o desactivar el inicio de sesión con contraseña local mediante la API de Identity. Console no expone un control separado de la política de contraseñas. Cuando configuras el primer proveedor SSO en Console, el inicio de sesión con contraseña permanece disponible hasta el primer inicio de sesión SSO exitoso. Auth desactiva entonces el inicio de sesión con contraseña local para ese tenant. Las integraciones de API pueden definir explícitamente la política de contraseñas cuando necesitan una transición diferente:
  • Desactivar el inicio de sesión con contraseña inmediatamente después de configurar el proveedor.
  • Mantener disponible el inicio de sesión con contraseña junto con SSO.
Prueba SSO antes de desactivar el inicio de sesión con contraseña local. Un secreto de cliente, emisor, dominio o URL de callback no válidos pueden impedir que todos los usuarios inicien sesión.

​
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

Configura SSO en Console

Prueba, guarda, revisa y elimina el proveedor del tenant.

Requisitos de despliegue de SSO

Configura las URLs de callback, el enrutamiento público de Auth y la resolución del tenant.

Autenticación multifactor

Agrega un segundo paso de verificación después de SSO.