Identidad en un LMS: SSO, altas, matrículas y bajas

Una persona entra en el campus con su cuenta corporativa, pero no ve el curso que necesita. Otra deja la organización y conserva una sesión abierta. Los dos casos pueden aparecer en una integración cuyo inicio de sesión se ha probado correctamente. El acceso delegado solo explica una parte del recorrido.

Al diseñar la identidad de un LMS conviene separar autenticación, cuenta, matrícula, permisos y sesión. Sus estados cambian por motivos distintos. El contrato entre sistemas debe indicar quién comunica esos cambios, qué efecto tienen y cómo se comprueba el resultado cuando llega tarde un mensaje o falla una operación.

Lo que una petición de SSO deja por decidir

El expediente S-03423-2026 de RTVE, relativo a su plataforma formativa, incluye documentación y aclaraciones sobre la integración. Las preguntas publicadas sobre protocolo, intercambio de datos y tiempos muestran por qué una petición de SSO necesita concretarse antes de estimar el trabajo. Citar este expediente no implica que haya participado en él ni que conozca su instalación.

El protocolo permite precisar cómo se comunica la identidad. Después siguen abiertas otras decisiones: dónde nace la cuenta, qué identificador se conserva, de qué sistema procede la matrícula y qué ocurre cuando una persona cambia de situación. Esas preguntas pertenecen a responsables diferentes y se deben reunir en un mismo acuerdo verificable.

La documentación de autenticación de Moodle y la de métodos de matriculación describen mecanismos separados. Tener una cuenta y poder autenticarse no equivale a estar matriculado en un curso. Esa separación es el punto de partida del contrato, no una excepción que deba resolver soporte después.

Un identificador que sobreviva a un cambio de correo

El correo sirve para comunicarse y puede intervenir en el acceso, pero cambia, puede corregirse y en algunas organizaciones se reutiliza. Si se elige como única clave entre sistemas, hay que asumir explícitamente esas consecuencias. Una alternativa es conservar un identificador estable de la fuente y su correspondencia con el usuario del LMS.

El contrato debe fijar el ámbito de ese identificador. Un número de empleado puede ser único dentro de una organización y colisionar al integrar otra. También debe distinguir a una persona de sus relaciones: puede cursar una formación y tutorizar otra. Fusionar cuentas por parecido de nombre o correo exige una decisión controlada, no una coincidencia silenciosa.

En el ejemplo uso identificadores ficticios y un sistema de referencia abstracto. No presupongo que todas las organizaciones tengan un único directorio capaz de decidir matrículas, relaciones laborales y conservación de expedientes.

Qué efecto tiene cada cambio

En Moodle, suspender una cuenta impide iniciar sesión y utilizar servicios web. La eliminación es una operación distinta y puede destruir datos. Por eso el contrato no debería traducir cualquier baja administrativa a «borrar usuario». La conservación del expediente y la retirada del acceso necesitan decisiones separadas de sus responsables.

También hay que ensayar las sesiones que ya estaban abiertas y los accesos a herramientas externas. El cierre de sesión federado depende de los mecanismos implantados; retirar una matrícula tampoco describe, por sí solo, el estado de una sesión en otro sistema. Si un canal queda fuera del acuerdo, debe figurar como límite comprobable.

Cuando los mensajes llegan repetidos o fuera de orden

Supongamos un alta seguida de una baja. La baja se aplica y, después, un reintento entrega otra vez el alta antigua. Un receptor que obedezca cualquier mensaje recibido podría reactivar una cuenta que ya no debe estar activa.

Para este ejemplo propongo identificar los eventos y conservar una revisión creciente por identidad. Repetir el mismo evento no vuelve a aplicarlo; recibir una revisión anterior tampoco hace retroceder el estado. Es una decisión de diseño que exige una fuente capaz de emitir y conservar esa revisión. Si hay varios productores o no existe ese orden, hará falta otro mecanismo de resolución y conciliación.

El fallo parcial merece otra prueba: la cuenta se crea, pero la matrícula no llega a aplicarse. El reintento tiene que continuar sin duplicar la identidad y dejar visible qué operación sigue pendiente. No basta con un mensaje genérico de «sincronización completada». El equipo de soporte necesita saber qué ocurrió, qué puede repetir y quién decide cuando los dos sistemas discrepan.

Contrato descargable y ejemplo ejecutable

El contrato de identidad para un LMS deja campos para la fuente, el identificador, las operaciones, los responsables, los plazos y los criterios de aceptación. Es una plantilla para adaptar a una integración concreta.

El ejemplo ejecutable de eventos de identidad comprueba, con datos ficticios, un alta, una baja, un reintento duplicado y un alta antigua recibida después de la baja. Se ejecuta con node ejemplo-identidad.mjs y no necesita credenciales ni realiza conexiones de red. El resultado esperado es que el estado final permanezca suspendido.

La prueba valida únicamente esa regla de transición en memoria. No implementa un proveedor de identidad, un conector Moodle ni una revocación de sesiones. Tampoco resuelve persistencia, concurrencia, autorización del emisor o reconciliación entre sistemas. Esos límites quedan indicados junto al código para que el ejemplo no se confunda con una integración preparada para producción.

La aceptación llega hasta el curso

La comprobación termina donde trabaja la persona: acceder al curso correcto, realizar la operación permitida y perder el acceso que corresponda cuando cambie su relación. Dirección académica, identidad y operación deben acordar ese resultado y saber a quién corresponde cada excepción.

El marco de interoperabilidad permite situar este contrato entre los demás intercambios de la plataforma. Si la duda es qué mecanismo usar para conectar una herramienta, la comparación entre LTI 1.3, API y xAPI delimita otra decisión. Elegir un protocolo ayuda a construir la integración; definir y comprobar el ciclo de vida permite sostenerla después.