En una universidad, una sola persona puede necesitar acceder al sitio web principal, un portal para el profesorado, el sistema de la biblioteca, una plataforma de aprendizaje y una docena de aplicaciones más — y nadie quiere iniciar sesión por separado en cada una de ellas. El inicio de sesión único (SSO, por sus siglas en inglés) resuelve este problema al permitir que un usuario se autentique una sola vez, con un único conjunto de credenciales institucionales, y obtenga acceso a todos los sistemas conectados. Para un sitio Drupal que se encuentra en el centro de la presencia digital de una universidad, integrarlo con el SSO de la institución es una de las piezas más importantes de todo el desarrollo.
Esta guía explica cómo funciona la integración de SSO en Drupal y, lo que es más importante, cómo elegir el enfoque adecuado. Cubriremos las cuatro tecnologías en las que se apoyan las universidades — SAML, Shibboleth, LDAP y CAS — cuándo se ajusta cada una, cómo funciona la integración en el lado de Drupal, y las decisiones de gobernanza de identidad y seguridad que la mayoría de las guías paso a paso pasan por alto.
Qué significa realmente el inicio de sesión único
El inicio de sesión único es un modelo de autenticación en el que un usuario inicia sesión una sola vez ante una autoridad central de confianza y luego es reconocido automáticamente por cada aplicación conectada a ella. El principio clave — y el beneficio de seguridad — es que las aplicaciones individuales nunca manejan la contraseña del usuario. Con SSO implementado, las credenciales se verifican en un solo lugar, bajo un único conjunto de políticas, en lugar de ser almacenadas y comprobadas por separado por cada sistema.
Para una universidad, esto importa en varios niveles a la vez. Los estudiantes y el personal obtienen una identidad única en decenas de servicios. El equipo de TI gestiona la autenticación de forma centralizada, aplicando reglas de contraseñas coherentes y autenticación multifactor en todas partes. Y cuando alguien deja la institución, desactivar una cuenta central corta el acceso a todo, en lugar de dejar inicios de sesión huérfanos dispersos por los sistemas. Esta combinación de comodidad y control es la razón por la que el SSO es, en la práctica, un requisito para cualquier plataforma web institucional seria.
El bloque fundamental: Proveedor de Identidad y Proveedor de Servicio
Toda configuración de SSO involucra dos roles, y entenderlos hace que todo lo demás sea más claro.
El Proveedor de Identidad (IdP) es la autoridad central de confianza que almacena las identidades de los usuarios y verifica las credenciales — el servicio Shibboleth de la institución, su Active Directory o su servidor CAS. El Proveedor de Servicio (SP) es la aplicación a la que el usuario quiere acceder — en este caso, el sitio Drupal. Cuando un usuario intenta acceder al SP de Drupal, este delega la autenticación al IdP; el IdP verifica al usuario y envía una confirmación de vuelta, junto con atributos como el nombre, el correo electrónico y el rol; y Drupal concede entonces el acceso basándose en esa respuesta confiable. En la configuración universitaria estándar, Drupal actúa como Proveedor de Servicio y el sistema existente de la institución es el Proveedor de Identidad. Establecer bien esta relación es la base de toda integración de SSO.
Los cuatro enfoques: SAML, Shibboleth, LDAP y CAS
Las universidades suelen apoyarse en una de cuatro tecnologías para el SSO. Se superponen en su propósito, pero difieren en origen, mecanismo y en dónde encajan mejor.
SAML
SAML (Security Assertion Markup Language) es el estándar abierto en el que se basa la mayoría de los sistemas SSO empresariales modernos. Es un protocolo basado en XML para intercambiar datos de autenticación y autorización entre un IdP y un SP, y se integra prácticamente con cualquier plataforma de identidad importante — Microsoft Entra ID, Okta, ADFS, Google Workspace, entre otras. En Drupal, SAML se gestiona a través de módulos contribuidos que permiten que el sitio actúe como Proveedor de Servicio, delegando la autenticación a cualquier IdP compatible con SAML. Es la opción más ampliamente compatible y el terreno común que la mayoría de los demás sistemas pueden entender.
Shibboleth
Shibboleth es una implementación específica y ampliamente desplegada de SAML, profundamente arraigada en el mundo académico. Es la columna vertebral del acceso federado en la educación superior y la investigación — la tecnología detrás de las federaciones académicas nacionales e internacionales que permiten a un estudiante iniciar sesión en una institución y acceder a recursos en otra. Técnicamente, integrar Drupal con Shibboleth es una integración SAML: Drupal actúa como Proveedor de Servicio SAML y Shibboleth funciona como Proveedor de Identidad. Si tu institución forma parte de una federación de identidad académica, es muy probable que Shibboleth sea el sistema al que te conectarás.
LDAP
LDAP (Lightweight Directory Access Protocol) no es un protocolo de SSO en el mismo sentido que SAML — es un protocolo para consultar un directorio de usuarios, comúnmente Microsoft Active Directory. Su papel en una universidad es el de ser la fuente subyacente de identidad: almacena quién existe, sus membresías de grupo y sus atributos. La integración de Drupal con LDAP permite a los usuarios iniciar sesión con sus credenciales de directorio y puede aprovisionar cuentas de Drupal y asignar roles automáticamente en función de los grupos del directorio. LDAP suele ser la capa que se sitúa detrás de un protocolo de SSO, en lugar de un sustituto de este, y es especialmente común donde la institución opera sobre la pila de Microsoft.
CAS
CAS (Central Authentication Service) es un protocolo de SSO de código abierto con raíces en la Universidad de Yale, y sigue siendo ampliamente utilizado en la educación superior. Fue diseñado específicamente para el problema del SSO en aplicaciones web, y funciona cómodamente junto a almacenes de autorización como LDAP. En Drupal, la integración con CAS redirige a los usuarios al servidor CAS central de la institución para autenticarse, y luego los devuelve al sitio como usuarios con sesión iniciada, con roles asignables según la respuesta de CAS. Para las universidades que ya operan un despliegue de CAS a nivel de todo el campus, conectar Drupal a él es una opción natural.
¿Qué protocolo debería elegir una universidad?
En la práctica, la elección suele venir dictada por lo que la institución ya utiliza — Drupal se conecta al IdP existente, y no al revés. La tabla a continuación resume cuándo encaja cada enfoque.
| Enfoque | Qué es | Mejor uso |
|---|---|---|
| SAML | Estándar abierto para autenticación federada; la compatibilidad más amplia. | Conexión con Entra ID, Okta, ADFS o cualquier IdP SAML. |
| Shibboleth | Implementación académica de SAML; el estándar de las federaciones de investigación. | Instituciones dentro de una federación académica nacional o internacional. |
| LDAP | Protocolo de directorio; fuente subyacente de la identidad del usuario. | Entornos de Microsoft Active Directory; aprovisionamiento de roles. |
| CAS | Protocolo de SSO de código abierto enfocado en la web, común en los campus. | Instituciones con un servidor CAS existente a nivel de todo el campus. |
La regla práctica es sencilla: identifica el proveedor de identidad que tu institución ya opera y, después, elige la integración de Drupal que se comunique con él. Una universidad dentro de una federación académica conecta Drupal con Shibboleth; una estandarizada en Microsoft se conecta mediante SAML a Entra ID o mediante LDAP a Active Directory; una que opera un servidor CAS de campus se conecta a CAS. Rara vez se trata de una elección desde cero — la respuesta correcta suele venir determinada por la infraestructura de identidad que ya está en funcionamiento.
Cómo funciona el SSO en el lado de Drupal
En el lado de Drupal, el SSO se gestiona mediante módulos contribuidos en lugar del núcleo, y existe un ecosistema maduro para cada protocolo. Sea cual sea el módulo utilizado, la integración se encarga de algunas tareas esenciales: redirige a los usuarios no autenticados al IdP, recibe y valida la respuesta de autenticación, y mapea los atributos que devuelve el IdP hacia una cuenta de Drupal.
Un concepto que vale la pena entender aquí es el aprovisionamiento "justo a tiempo" (JIT). En lugar de crear una cuenta de Drupal de antemano para cada usuario posible, el aprovisionamiento JIT crea la cuenta automáticamente la primera vez que una persona se autentica correctamente a través del IdP, rellenándola con los atributos que el IdP proporciona — nombre, correo electrónico y rol. Esto es lo que permite que el SSO escale a toda una universidad: ningún administrador tiene que crear manualmente miles de cuentas, y la asignación de roles puede ser gestionada automáticamente según las membresías de grupo que reporta el IdP. Para las instituciones que evalúan los módulos específicos, las páginas oficiales de proyecto en Drupal.org de SimpleSAMLphp Authentication, LDAP y CAS documentan las opciones actuales y compatibles.
Gobernanza de identidad: la parte que la mayoría de las guías omiten
La mayoría de los tutoriales de SSO se detienen una vez que el inicio de sesión funciona. Pero para una universidad que maneja datos sensibles de estudiantes y personal, las preguntas más difíciles y más importantes son las de gobernanza: quién tiene acceso, cómo se elimina el acceso, y dónde reside realmente la identidad. Aquí es donde una integración bien diseñada se distingue de una que simplemente funciona.
El principio central es que Drupal no debería mantener su propio conjunto separado de cuentas de usuario junto al proveedor de identidad institucional. Cuando existen cuentas locales de Drupal de forma independiente, se desincronizan con el tiempo: no se desactivan cuando alguien se va, y acumulan contraseñas débiles con el paso del tiempo. La práctica recomendada es desactivar la autenticación local por contraseña para todos, excepto para una única cuenta de administrador de emergencia ("break-glass"), enrutar toda la autenticación a través del IdP, y heredar de esa fuente central la autenticación multifactor, la política de contraseñas y el ciclo de vida de las cuentas de la institución. En otras palabras, el sistema de identidad de la institución — y no Drupal — se convierte en la única fuente de verdad sobre quién puede iniciar sesión.
Este enfoque ofrece un beneficio de seguridad concreto: la desprovisión. Cuando un estudiante se gradúa o un miembro del personal se marcha, desactivar su cuenta de identidad central corta de inmediato su acceso a Drupal junto con todo lo demás, sin dejar atrás ningún inicio de sesión local huérfano. Para una institución responsable de la protección de datos, ese único interruptor centralizado es mucho más seguro que intentar rastrear cuentas separadas en cada sistema.
Escenarios universitarios: multisitio, ciclo de vida y exalumnos
El SSO en un contexto universitario trae consigo algunos escenarios que un sitio corporativo único nunca encuentra:
- Inicio de sesión único multisitio: Las grandes universidades gestionan muchos sitios — un sitio principal más sitios separados para facultades, departamentos y centros de investigación. El SSO permite a un usuario iniciar sesión una vez y desplazarse por todos ellos sin problemas, mientras la autenticación se mantiene centralizada. Esto encaja de forma natural con la arquitectura multisitio de Drupal, donde muchos sitios se gestionan desde un solo lugar.
- El ciclo de vida de la identidad: La relación de una persona con una universidad cambia con el tiempo — solicitante, estudiante, graduado y, a veces, personal — y sus necesidades de acceso cambian con ella. Basar los roles de Drupal en los atributos del IdP significa que el acceso puede seguir ese ciclo de vida automáticamente, en lugar de ajustarse manualmente en cada transición.
- Poblaciones diferenciadas: Estudiantes, profesorado, personal y exalumnos suelen necesitar distintos niveles de acceso a diferentes sistemas. Como el IdP reporta la membresía de grupo, Drupal puede mapear automáticamente cada población al rol adecuado, manteniendo los permisos alineados con el estado real del usuario.
Estos escenarios son precisamente la razón por la que la integración de identidad es una parte central en la construcción de una plataforma universitaria, y no una idea de último momento. También se conectan con el conjunto más amplio de integraciones académicas que suele necesitar un sitio Drupal — entre ellas, una plataforma de aprendizaje, que cubrimos en nuestra guía sobre la integración de Moodle y Drupal.
Errores comunes de SSO y cómo evitarlos
- Mantener cuentas locales junto al IdP: El fallo de gobernanza más común. Las cuentas de Drupal independientes se desincronizan, no se desprovisionan y acumulan contraseñas débiles. Enruta la autenticación a través del IdP y conserva localmente solo una cuenta de administrador de emergencia.
- Olvidar la cuenta de emergencia: Si cada inicio de sesión depende del IdP y este deja de estar disponible, nadie podrá entrar — ni siquiera los administradores. Una única cuenta de emergencia local bien protegida evita un bloqueo total.
- Mapear roles sin cuidado: Conceder automáticamente roles elevados de Drupal a partir de los atributos del IdP puede otorgar acceso administrativo de forma no intencionada. Mapea cada atributo al privilegio mínimo que necesita y trata los roles administrativos con especial escrutinio.
- Ignorar la desprovisión: Centrarse solo en que el inicio de sesión funcione deja sin respuesta la pregunta más importante — cómo se elimina el acceso. Diseña pensando en el momento en que alguien se va, no solo en el momento en que se une.
- Elegir un protocolo de forma aislada: Elegir una tecnología de SSO sin comprobar qué utiliza ya la institución genera una complejidad innecesaria. Parte del proveedor de identidad existente y conéctate a él.
- Descuidar el mapeo de atributos: Si los atributos del IdP no se mapean correctamente a los campos y roles de Drupal, los usuarios pueden iniciar sesión pero acabar con los permisos equivocados. Confirma el mapeo de atributos con la misma atención con la que confirmas el propio flujo de inicio de sesión.
Hecho correctamente, la integración de SSO convierte un sitio Drupal en una parte fluida y segura del ecosistema digital de una universidad — una sola identidad, gobernada de forma centralizada, que abarca todos los sistemas conectados. Es una capacidad fundamental para cualquier institución que ejecute Drupal a gran escala, y forma parte del conjunto más amplio de integraciones académicas que exploramos en nuestro resumen sobre Drupal en la educación.
Preguntas frecuentes sobre el SSO en Drupal
¿Almacena Drupal las contraseñas cuando el SSO está habilitado?
No — ese es el beneficio de seguridad principal del SSO. Cuando la autenticación se delega a un proveedor de identidad, las credenciales del usuario son verificadas por el IdP y nunca se almacenan en Drupal. La configuración recomendada desactiva por completo la autenticación local por contraseña, excepto para una única cuenta de administrador de emergencia reservada para casos urgentes. Esto significa que las contraseñas, la política de contraseñas y la autenticación multifactor residen todas en el sistema de identidad central de la institución, y Drupal simplemente confía en su respuesta verificada.
¿Puede Drupal usar más de un proveedor de identidad a la vez?
Sí, dependiendo de los módulos utilizados, Drupal puede configurarse para trabajar con múltiples fuentes de autenticación. Un ejemplo común es una institución que autentica a los estudiantes a través de un sistema y al personal a través de otro, o que mantiene SAML para la mayoría de los usuarios mientras conserva una opción local limitada para un grupo específico. La configuración se vuelve más compleja con cada fuente adicional, por lo que el consejo práctico es admitir únicamente los proveedores de identidad para los que exista una necesidad real, y mantener la configuración tan sencilla como lo permitan los requisitos reales de la institución.
¿Cuál es la diferencia entre autenticación y aprovisionamiento?
La autenticación consiste en verificar quién es un usuario — confirmar sus credenciales frente al proveedor de identidad. El aprovisionamiento consiste en crear y mantener la cuenta y los atributos del usuario en Drupal. El SSO se encarga de la autenticación; el aprovisionamiento "justo a tiempo" se encarga de la creación de la cuenta que sigue, generando una cuenta de Drupal automáticamente en el primer inicio de sesión y rellenándola a partir de los atributos del IdP. Ambos trabajan juntos: la autenticación demuestra la identidad, y el aprovisionamiento le otorga a esa identidad un lugar y un rol dentro de Drupal.
¿Es mejor SAML o CAS para una universidad?
Ninguno de los dos es universalmente mejor — depende de lo que tu institución ya utilice. SAML, incluyendo su implementación académica Shibboleth, es la opción adecuada para instituciones dentro de federaciones de investigación o estandarizadas en plataformas de identidad como Entra ID u Okta. CAS es una opción sólida para universidades que ya operan un servidor CAS a nivel de todo el campus. La decisión debería seguir a la infraestructura de identidad existente en lugar de a una clasificación abstracta: conecta Drupal al sistema en el que tu institución ya confía, y deja que eso determine el protocolo.