Saltar al contenido
Todos los artículos

Seguridad

Cómo configurar el inicio de sesión único SAML en tu LMS con Entra ID, Okta o Google Workspace

Guía práctica del SSO con SAML en un LMS: términos clave, pasos para Entra ID, Okta y Google Workspace, lista de pruebas y errores que conviene evitar.

Equipo de Acadenix · · 8 min de lectura


Cada inicio de sesión independiente es una contraseña más que restablecer y una cuenta más que cerrar cuando alguien se va. El inicio de sesión único (SSO) con SAML conecta tu sistema de gestión del aprendizaje con tu proveedor de identidad, de modo que las personas acceden a la formación con su cuenta de trabajo y el acceso sigue a tu directorio. Aquí te explicamos cómo funciona SAML, cómo se configura con Microsoft Entra ID, Okta o Google Workspace y qué comprobar antes de ponerlo en producción.

Cómo funciona el inicio de sesión único SAML

SAML (Security Assertion Markup Language) 2.0 es un estándar abierto para transmitir información de inicio de sesión entre dos sistemas que confían el uno en el otro. El LMS nunca ve la contraseña de la persona: la envía a tu proveedor de identidad, que comprueba quién es, con la autenticación multifactor que exijas, y la devuelve con una declaración firmada.

Término Qué significa
Proveedor de identidad (IdP) El sistema que autentica a tus usuarios, como Entra ID, Okta o Google Workspace.
Proveedor de servicio (SP) La aplicación en la que las personas inician sesión: tu LMS.
Aserción La declaración XML firmada del IdP: quién es la persona, cuándo inició sesión y atributos como el correo electrónico y el nombre.
Entity ID Un nombre único para cada parte, a menudo con forma de URL pero que es solo un identificador. Debe coincidir exactamente.
ACS URL La Assertion Consumer Service URL: la dirección del LMS que recibe la respuesta del IdP.
Certificado de firma El IdP firma con su clave privada; el LMS verifica con el certificado público del IdP y rechaza las aserciones falsificadas o alteradas.
Metadatos Un archivo XML que reúne un entity ID, los puntos de conexión y los certificados, listo para importar.

Las aserciones tienen una vida corta e indican su destinatario (el entity ID del SP). El SP rechaza todo lo que haya caducado o esté destinado a otra aplicación.

Por qué merece la pena el SSO en un LMS

  • Sin contraseñas adicionales. Las personas usan su cuenta de siempre, y tu MFA y tus políticas de acceso cubren también la formación.
  • Las nuevas incorporaciones acceden rápido. Asigna la aplicación del LMS a un grupo y el personal nuevo que esté en él podrá iniciar sesión desde el primer día.
  • Quien se va pierde el acceso en el origen. Desactiva a alguien en tu directorio y no podrá iniciar una nueva sesión en el LMS. SAML controla el inicio de sesión, no la cuenta, así que archiva también la cuenta del LMS como parte del proceso de salida.

Creación de cuentas just-in-time

Con el aprovisionamiento just-in-time (JIT), el LMS crea una cuenta la primera vez que alguien inicia sesión, a partir de los atributos de la aserción, de modo que no hay que importar ninguna lista de usuarios. Ponle límites:

  • Restríngelo a tus propios dominios de correo electrónico, para que una aplicación mal configurada o una cuenta de invitado no cree usuarios sueltos.
  • Da a las cuentas nuevas el rol más bajo y concede los derechos de administrador de forma deliberada.
  • Identifica a las personas mediante un identificador estable cuando tu IdP pueda enviarlo, porque las direcciones de correo cambian.

Inicio de sesión iniciado por el SP frente al iniciado por el IdP

  • Iniciado por el SP: la persona abre el LMS, que envía una solicitud de autenticación al IdP, y el IdP envía su respuesta a la ACS URL. Funciona desde marcadores y enlaces de correo, y se considera en general el flujo más seguro porque la respuesta atiende una solicitud que hizo el LMS.
  • Iniciado por el IdP: la persona hace clic en el icono de la aplicación en Microsoft My Apps, en su panel de Okta o en el menú de aplicaciones de Google, y el IdP envía a la ACS URL una respuesta que nadie ha solicitado.

Puedes ofrecer ambos; prueba cada uno.

Configuración del SSO con SAML, paso a paso

La secuencia es prácticamente la misma en todas partes:

  1. Planifica el alcance: quién usa el SSO, qué grupos reciben la aplicación, qué dominios de correo electrónico se permiten y qué atributo identifica a cada persona.
  2. Crea la conexión en el LMS y anota su entity ID y su ACS URL.
  3. Crea una aplicación SAML en tu IdP con esos valores, elige el formato de NameID y agrega los atributos de correo electrónico, nombre y apellido.
  4. Asigna usuarios o grupos; las personas no asignadas normalmente son rechazadas.
  5. Proporciona al LMS los datos del IdP: una URL de metadatos, un archivo de metadatos, o bien el entity ID del IdP, la URL de inicio de sesión y el certificado de firma.
  6. Asigna los atributos a los nombres que tu IdP envía realmente.
  7. Prueba y luego actívalo, y avisa a las personas de lo que va a cambiar.

Notas por proveedor

La documentación de tu proveedor tiene las pantallas exactas. Conviene saber lo siguiente:

  • Microsoft Entra ID: usa una aplicación empresarial que no sea de la galería, no un registro de aplicación, que no ofrece SAML. Los nombres de las notificaciones (claims) son URI largos, así que cópialos exactamente. El ID de objeto es un buen identificador estable. Para las personas sin buzón, la notificación de correo electrónico puede estar vacía; el nombre principal de usuario puede sustituirla si es una dirección real.
  • Okta: crea una integración de aplicación SAML 2.0. Los nombres de las declaraciones de atributos los defines tú, así que deben coincidir exactamente con la asignación del LMS, incluidas las mayúsculas y minúsculas. Su ID de usuario interno es un identificador estable.
  • Google Workspace: agrega una aplicación SAML personalizada y descarga su archivo de metadatos. La aplicación empieza desactivada, así que actívala para las unidades organizativas o los grupos adecuados. Una configuración típica identifica a las personas por su correo electrónico principal, así que ten en cuenta las direcciones renombradas y reutilizadas.

Lista de comprobación de pruebas

Antes de ponerlo en producción, comprueba lo siguiente en una ventana privada del navegador:

  • Un usuario existente inicia sesión empezando desde el LMS y, de nuevo, desde el icono de la aplicación.
  • Un usuario nuevo de tu dominio obtiene una cuenta con el rol correcto.
  • Alguien que no está asignado a la aplicación es rechazado.
  • Alguien fuera de tus dominios permitidos es rechazado.
  • El correo electrónico, el nombre y el apellido llegan correctamente.
  • Un administrador sigue pudiendo entrar por la vía de recuperación.

Errores habituales

Desfase de reloj

Si los relojes del IdP y del LMS difieren más de lo que tolera el LMS, se rechazan aserciones correctas por no ser todavía válidas o por haber caducado ya. Afecta sobre todo a los servidores de identidad alojados por cuenta propia, así que mantén sus relojes sincronizados.

Renovación de certificados

Los certificados de firma del IdP caducan y, si el LMS no confía en el certificado de reemplazo, todos los inicios de sesión fallan a la vez. Anota la fecha de caducidad en tu agenda. Si tu LMS puede confiar en dos certificados, agrega primero el nuevo allí y después actívalo en el IdP; si no, cambia ambos lados a la vez en un momento de poca actividad. Haz la prueba de inmediato.

Asignación de atributos

Los nombres de atributos suelen compararse de forma exacta: un LMS que espera email no aceptará Email. Comprueba también el identificador. Un NameID transitorio cambia en cada sesión y una dirección de correo puede cambiar; un NameID persistente o un atributo de ID inmutable son estables. Si identificas a las personas por su correo electrónico, archiva la cuenta de quien se va antes de que su dirección se reasigne.

Dominios de correo que no coinciden

Los directorios suelen incluir personas cuyo nombre de inicio de sesión no es su dirección de correo electrónico, contratistas de otros dominios y personal de empresas adquiridas que sigue en los dominios antiguos. Si el LMS limita las cuentas a ciertos dominios, serán rechazados. Haz una lista de todos los dominios antes de la puesta en producción.

Cómo lo hace Acadenix

El SSO con SAML está en el plan Gold, con guías paso a paso para Entra ID, Okta y Google Workspace.

  • Prueba y luego activa. Guardas los datos de tu IdP como borrador, ejecutas Test configuration (probar configuración) iniciando sesión en tu proveedor y solo entonces lo activas. Si falta la notificación de correo electrónico, se te indica cuáles son los nombres de notificaciones que tu proveedor sí envió.
  • Cambios por etapas. Un certificado o un tenant nuevo se incorpora como una actualización de la configuración, y la configuración actual sigue funcionando hasta que la actives.
  • JIT dentro de tus dominios. Quien no tiene cuenta obtiene una cuenta de alumno en su primer inicio de sesión, solo si su correo electrónico pertenece a los dominios de registro de tu organización, y puedes desactivar esta opción. Cuando alguien que ya tiene una cuenta de Acadenix inicia sesión por primera vez a través de tu IdP, Acadenix le envía por correo electrónico un código de un solo uso para confirmar el vínculo. Esto ocurre una vez por persona.
  • Dos formas de entrar. Las personas empiezan desde tu página de inicio de sesión, que puede llevarlas directamente a tu IdP o mostrar un botón, o desde el icono en My Apps, Okta o Google.
  • Una conexión, una organización. Una conexión SAML no se transmite a las organizaciones situadas por debajo de su propietaria, lo cual importa para grupos con muchas sedes.
  • Una vía de recuperación. Si tu IdP deja de funcionar, los administradores todavía pueden iniciar sesión con un código de un solo uso enviado por correo electrónico, y esta opción no se puede desactivar.

Además de SAML, las personas pueden iniciar sesión con un código enviado por correo electrónico o con una cuenta de Google, Microsoft o LinkedIn. Más información en nuestra página de seguridad.

Puntos clave

  • Intercambia los entity ID, la ACS URL y los metadatos, y luego asigna un identificador estable y un correo electrónico verificado.
  • Limita las cuentas just-in-time a tus propios dominios y al rol más bajo.
  • Prueba los dos flujos de inicio de sesión, los rechazos y la vía de recuperación antes de la puesta en producción.
  • Anota en tu agenda la caducidad de los certificados y archiva las cuentas del LMS de quienes se van.

¿Quieres conectar Acadenix con tu proveedor de identidad? Compara los planes en nuestra página de precios o habla con nosotros sobre tu configuración.

Preguntas frecuentes

Acceso de administrador a tu proveedor de identidad y al LMS. El LMS te da su entity ID y su ACS URL, tu proveedor de identidad te da sus metadatos (entity ID, URL de inicio de sesión y certificado de firma), y tú acuerdas qué atributos identifican a cada persona.
Sí, si el LMS admite el aprovisionamiento just-in-time, que crea una cuenta la primera vez que alguien inicia sesión. En Acadenix son cuentas de alumno, creadas solo para las personas cuya dirección de correo electrónico pertenece a los dominios de registro de tu organización.
Las personas que dependen del SSO no pueden iniciar sesión hasta que vuelva a funcionar, así que conviene mantener una vía de recuperación para los administradores. En Acadenix, los administradores siempre pueden iniciar sesión con un código de un solo uso enviado por correo electrónico, y esa vía no se puede desactivar.
El inicio de sesión iniciado por el SP, en el que las personas empiezan desde el LMS, se considera en general el flujo más seguro, porque la respuesta está vinculada a una solicitud que hizo el LMS. El inicio de sesión iniciado por el IdP desde el icono de una aplicación es cómodo, y puedes ofrecer ambos.

Sigue leyendo

¿Listo para sacar la carga administrativa de la formación?

Solicita una evaluación, sube tus cursos SCORM actuales y descubre cómo es Acadenix con tu propio contenido.

Iniciar sesión