El inicio de sesión único (SSO) permite que estudiantes y trabajadores entren a Moodle con la misma cuenta institucional que usan para el correo. Es de las mejoras con mejor relación entre esfuerzo y adopción, y también de las que más problemas causa cuando se activa sin depurar los datos. Somos el Moodle Certified Partner del Perú.
Qué resuelve el SSO y qué no
El SSO resuelve identidad: una sola credencial, una sola política de contraseñas y un solo lugar donde bloquear a alguien que deja la institución. No resuelve matrículas, roles ni permisos: quién está en qué curso sigue definiéndose en Moodle o mediante una sincronización aparte con el sistema académico o de recursos humanos.
El beneficio operativo más visible es la caída de tickets por contraseñas olvidadas, que en campus grandes concentran buena parte del soporte de primer nivel.
OAuth 2 o SAML2: cómo elegir
Moodle incluye en su núcleo el método de servicios OAuth 2, que conecta directo con Microsoft Entra ID o Google Workspace, y admite SAML2 mediante un plugin ampliamente usado en el sector universitario. La elección depende de si tu institución ya tiene un proveedor de identidad federado.
| Criterio | OAuth 2 (Microsoft / Google) | SAML2 |
|---|---|---|
| Escenario típico | Institución con M365 o Workspace | Proveedor de identidad central |
| Instalación en Moodle | Nativa | Plugin |
| Tiempo de configuración | Corto | Medio |
| Federación con otros sistemas | Limitada | Prevista por diseño |
| Mapeo de atributos | Básico | Detallado |
Si el proyecto además busca archivos y videoconferencia integrados, revisa nuestra guía de integraciones con Microsoft 365 y Google Workspace.
El punto crítico: cuentas duplicadas
Moodle vincula la identidad externa con el usuario local por correo electrónico. Si un docente estaba registrado con su correo personal y entra por SSO con el institucional, Moodle crea un usuario nuevo y su historial de cursos y calificaciones queda en la cuenta anterior. Ese es el incidente número uno al activar SSO.
- Exporta la lista de usuarios y detecta correos no institucionales.
- Actualiza correos antes de activar el método, no después.
- Define qué hacer con cuentas históricas sin equivalente institucional.
- Activa el SSO primero para un grupo piloto y valida el historial.
- Deja un método alterno para invitados y cuentas de servicio.
Altas, bajas y sincronización
El SSO controla el acceso, no el ciclo de vida del usuario. Para que quien se retira quede suspendido en Moodle y libere matrículas, hace falta activar la sincronización de usuarios desde el directorio institucional, con reglas explícitas de alta, actualización y baja.
En universidades esa sincronización suele apoyarse en el sistema académico por periodo; en empresas, en el directorio de personal, donde además importa el puesto para asignar programas obligatorios.
Errores frecuentes al activar SSO
Casi todos los problemas son de configuración previa, no de Moodle. Los más repetidos: activar el método sin depurar correos, no probar con un rol de estudiante real, olvidar el acceso administrativo alterno y no comunicar el cambio antes de una semana de exámenes.
- Quedarse sin acceso de administrador si el proveedor de identidad falla: conserva una cuenta local de emergencia.
- Botón de acceso poco visible en la página de inicio de sesión: renómbralo con el nombre institucional.
- Permitir autorregistro por correo en paralelo, lo que reabre la puerta a duplicados.
- No definir qué ocurre con estudiantes de extensión o de programas cortos sin cuenta institucional.
Cómo se ejecuta el proyecto
Un SSO bien hecho es un proyecto corto con etapas claras: diagnóstico de identidades, configuración en entorno de pruebas, piloto con un grupo, comunicación y despliegue. Lo que alarga el plazo casi siempre es la coordinación con el área de TI que administra el directorio, no la configuración en sí.
Nosotros lo abordamos dentro de la implementación de Moodle, con la depuración de usuarios como entregable explícito y documentación para el equipo administrador.
Piloto con un grupo controlado antes del despliegue
El SSO se activa para toda la institución en un solo paso, y ese es justamente el riesgo. Un piloto con entre veinte y cincuenta personas de perfiles distintos (docentes, personal administrativo, estudiantes de un ciclo) permite detectar problemas antes de que lleguen a la mesa de ayuda multiplicados por miles.
El piloto debe cubrir cuatro escenarios reales: alguien que nunca inició sesión en el campus, alguien con una cuenta local previa que debe vincularse, alguien que entra desde la aplicación móvil y alguien que llega desde un enlace directo a un curso. Ese último caso es el que más falla: si la redirección posterior al inicio de sesión no conserva el destino, el usuario aterriza en la portada y se pierde.
Con el piloto cerrado se define la fecha de corte, el mensaje que verán quienes aún usen contraseña local y el período de convivencia entre ambos métodos. Ese plan forma parte del alcance de una implementación de Moodle acompañada por el partner.
Seguridad: MFA, sesiones y cierre de sesión
Integrar el campus con el directorio institucional traslada la política de seguridad al proveedor de identidad. Eso es una ventaja: el segundo factor, la caducidad de contraseñas y el bloqueo por intentos fallidos se administran en un solo lugar y Moodle los hereda sin configuración adicional.
Hay tres decisiones que conviene tomar explícitamente. La primera es qué ocurre con el cierre de sesión: cerrar sesión en Moodle no siempre cierra la sesión del proveedor, y en laboratorios o aulas compartidas eso deja cuentas abiertas. La segunda es la duración de la sesión en el campus, que debería ser coherente con la del directorio. La tercera es quién conserva acceso local de emergencia, porque si el proveedor de identidad cae y nadie puede entrar como administrador, la recuperación se complica.
Conviene documentar esas tres decisiones antes del despliegue y revisarlas en cada auditoría interna. La operación diaria de ese esquema es parte del soporte especializado de Moodle.
El día después: soporte y mesa de ayuda
Con SSO activo, la naturaleza de los tickets cambia. Ya casi no llegan pedidos de restablecimiento de contraseña, pero aparecen consultas nuevas: usuarios que existen en el directorio y no ven sus cursos, personas con dos cuentas por un cambio de correo, o docentes externos que no están en el directorio institucional y necesitan acceso.
Vale la pena preparar a la mesa de ayuda con un guion corto: cómo verificar si la cuenta llegó desde el proveedor de identidad, cómo identificar una cuenta duplicada, a quién escalar cuando el problema está en el directorio y no en Moodle, y qué hacer con usuarios externos. Ese último grupo suele resolverse con un método de autenticación secundario y un proceso de aprobación claro, no con excepciones improvisadas.
Un registro de incidencias de los primeros treinta días muestra qué ajustar: mapeo de campos, reglas de vinculación o comunicación a usuarios. Después de ese período el SSO deja de ser un proyecto y pasa a ser infraestructura silenciosa.
Preguntas frecuentes
¿SSO significa que Moodle deja de tener usuarios?
No. Moodle sigue creando un usuario local por persona; lo que cambia es que la contraseña y la verificación de identidad las gestiona el proveedor de identidad institucional en lugar de Moodle.
¿Qué conviene, OAuth con Microsoft o Google, o SAML2?
Si la institución ya usa Microsoft 365 o Google Workspace y no tiene otros sistemas federados, OAuth 2 es más rápido de configurar. SAML2 conviene cuando existe un proveedor de identidad central que ya federa varios sistemas académicos.
¿Se pueden mantener cuentas manuales junto al SSO?
Sí. Moodle permite varios métodos de autenticación activos, lo que es útil para invitados externos y cuentas de servicio. Conviene documentar quién puede tener cuenta manual y revisarlo periódicamente.
¿El SSO da de baja automáticamente a quien sale de la institución?
Solo si se configura la sincronización de usuarios además del inicio de sesión. El SSO por sí solo impide el acceso cuando la cuenta institucional se desactiva, pero no suspende el usuario en Moodle ni libera matrículas.
¿Qué pasa con los usuarios que ya existían antes del SSO?
Se vinculan por correo electrónico si coincide con el de la cuenta institucional. Antes de activar el SSO hay que depurar correos personales y duplicados, o aparecerán cuentas paralelas sin historial.
¿Cuánto debería durar un piloto de SSO?
Entre dos y tres semanas con un grupo de veinte a cincuenta personas de perfiles distintos. Es tiempo suficiente para ver casos reales de vinculación de cuentas, accesos desde el móvil y enlaces directos a cursos.
¿El SSO habilita el segundo factor de autenticación en Moodle?
Moodle hereda la política del proveedor de identidad. Si el directorio institucional exige segundo factor, el ingreso al campus también lo exigirá, sin configuración adicional dentro de Moodle.
¿Qué pasa con los docentes externos que no están en el directorio institucional?
Se atienden con un método de autenticación secundario y un proceso de aprobación definido. Lo que no conviene es abrir excepciones caso por caso, porque con el tiempo vuelven a aparecer cuentas duplicadas.