Cómo configurar autenticación single sign-on SSO en Drupal para entornos corporativos

Qué es el SSO y por qué tu intranet lo necesita ya

Saber cómo configurar autenticación single sign-on SSO en Drupal para entornos corporativos empieza por entender la promesa que escuchas en todas las reuniones de IT: el usuario entra una vez y deja de pelearse con contraseñas. Técnicamente hablamos de autenticarse contra un proveedor de identidad central (el IdP) para acceder al CRM, al correo, a la intranet y a la web corporativa sin volver a teclear credenciales.

Si gestionas una empresa de cierto tamaño, el SSO ya no es opcional. Los tickets de help desk relacionados con contraseñas olvidadas se comen entre un 20% y un 50% del volumen de soporte. Eliminarlos libera al equipo técnico y cierra una de las vías más típicas para reciclar contraseñas débiles entre servicios.

Hay otra ventaja menos visible pero crítica: el ciclo de vida del usuario. Cuando alguien deja la empresa, basta con desactivar su cuenta en el IdP para que pierda acceso a todo en segundos. Sin SSO, alguien tiene que acordarse de revocar accesos en quince sistemas, y siempre se queda alguno fuera.

¿Y Drupal? Si tu web corporativa, tu portal de partners o tu intranet corren sobre Drupal, integrarlos en el flujo SSO cierra el círculo. Sin ese paso, el portal Drupal se convierte en la isla rara donde toca volver a identificarse.

Protocolos: SAML, OAuth/OIDC y LDAP, sin mitos

Antes de tocar un módulo, conviene saber qué protocolo encaja con tu realidad. Cada uno tiene su contexto natural y mezclarlos por ignorancia suele salir caro.

SAML 2.0, el clásico empresarial

Security Assertion Markup Language sigue siendo el protocolo dominante. Intercambia assertions XML firmadas entre el IdP y el proveedor de servicio (tu Drupal). Es robusto, está probado en escenarios exigentes y prácticamente cualquier IdP empresarial lo habla con fluidez.

Si ya tienes Azure AD, ADFS, Okta o PingFederate desplegado y necesitas integrar Drupal junto a aplicaciones legacy de RR. HH. o ERP, SAML es la apuesta segura.

OAuth 2.0 con OpenID Connect

OAuth 2.0 por sí solo es un framework de autorización, no de autenticación. Lo que convierte la pareja en una solución de SSO real es OpenID Connect, que añade la capa de identidad encima. OIDC es más moderno, más ligero y se lleva especialmente bien con aplicaciones móviles y APIs.

Es la opción natural cuando trabajas con Google Workspace, Auth0 o Keycloak, o cuando además del login web necesitas autenticar peticiones API.

LDAP, ni SSO ni dejarlo

LDAP no es propiamente un protocolo de SSO. Es un protocolo de acceso a directorios que muchas empresas siguen usando como capa de autenticación contra Active Directory. Permite entrar con credenciales corporativas, pero el usuario tendrá que reintroducirlas en cada aplicación: no hay sesión federada.

Si todavía no tienes un IdP moderno, LDAP cumple como transición. Para SSO de verdad, no es el destino.

Módulos de Drupal: qué instalar según el caso

El ecosistema de módulos contribuidos de Drupal cubre los tres protocolos. La elección depende del IdP, del nivel de personalización y de cuánto control quieras sobre la capa de autenticación.

SimpleSAMLphp Authentication

Conecta Drupal con la librería SimpleSAMLphp, que hace de Service Provider SAML. Es la opción más robusta y flexible para SAML serio. Requiere instalar SimpleSAMLphp como componente externo, lo que añade una pieza al stack pero te da control total sobre certificados, metadatos y mapeo de atributos.

OpenID Connect

El módulo openid_connect ofrece integración nativa con proveedores OIDC. Admite varios proveedores a la vez y se configura mucho más rápido que SAML. Soporta los flujos Authorization Code y Authorization Code con PKCE, lo que querrás para aplicaciones modernas.

LDAP

El módulo ldap autentica contra LDAP/Active Directory, sincroniza perfiles, mapea grupos a roles y aprovisiona cuentas. Trae varios submódulos (server, authentication, user, query, authorization); actívalos solo si los necesitas para no inflar la superficie de configuración.

Integración con los IdPs habituales en España

Cada proveedor tiene sus particularidades. Estos son los que aparecen más a menudo en proyectos corporativos españoles.

Microsoft Entra ID (antes Azure AD)

Es el rey en empresas con Microsoft 365. Soporta SAML y OIDC y normalmente recomendamos OIDC por sencillez. El flujo es: registras la aplicación en Entra ID, copias el Client ID y el Client Secret, configuras las URIs de redirección y declaras los scopes mínimos (openid, profile, email).

Google Workspace

Aquí lo natural es OIDC. Google publica endpoints estándar que el módulo openid_connect consume sin fricción. Solo necesitas crear las credenciales OAuth en Google Cloud Console y autorizar el dominio de tu Drupal.

Okta y Keycloak

Okta domina en multinacionales tecnológicas. Keycloak es la alternativa open source mantenida por Red Hat, perfecta para empresas que quieren control absoluto sin depender de un SaaS. Ambos hablan SAML y OIDC con buena integración Drupal; la diferencia operativa está en quién gestiona la infraestructura.

SAML con SimpleSAMLphp, paso a paso

Como es el caso más frecuente en entornos corporativos, vale la pena detallarlo.

Paso 1: instalar SimpleSAMLphp fuera del docroot

Descarga la librería y colócala fuera del document root de Drupal, por ejemplo en /var/simplesamlphp. Define un alias en Apache o un location block en Nginx para servir la ruta /simplesaml. Mantenerlo fuera del docroot evita exponer accidentalmente ficheros sensibles.

Paso 2: configurar Drupal como SP

Edita config.php para fijar baseurlpath, technicalcontact_email y un secretsalt único (no lo dejes con el valor por defecto, ese error sale en auditorías cada dos meses). Luego define tu Service Provider en authsources.php con el EntityID que vas a comunicar al IdP.

Paso 3: registrar los metadatos del IdP

Pide a tu administrador del IdP la URL de metadatos. Importarla es mucho más limpio que copiar XML a mano. Esos metadatos van en saml20-idp-remote.php.

Paso 4: activar y configurar el módulo en Drupal

Instala simplesamlphp_auth con Composer, actívalo y configura la ruta a la instalación de SimpleSAMLphp, el nombre de la fuente de autenticación y las opciones de comportamiento: si permites login local en paralelo, si creas usuarios al vuelo o si bloqueas todo lo que no venga del IdP.

Paso 5: mapeo de atributos

Define cómo se traducen los atributos SAML a campos Drupal: email, nombre, apellidos y cualquier campo personalizado que necesites. Este paso parece menor y luego es el que determina la calidad de toda la experiencia. Un mapeo mal hecho te genera usuarios duplicados, perfiles incompletos y permisos que no cuadran.

Roles automáticos y aprovisionamiento

Una de las cosas que más rentabilidad te da es dejar de gestionar permisos a mano.

De grupos del IdP a roles de Drupal

Mapeas grupos del directorio corporativo a roles de Drupal. Los del grupo "Marketing" entran como editores de contenido, los de "IT" como administradores, los de "Comercial" como autores de fichas de cliente. Cambias el grupo en el IdP y el rol cambia solo. Adiós a la hoja de Excel con los permisos.

Aprovisionamiento Just-in-Time

Con JIT, la cuenta Drupal se crea la primera vez que el usuario entra vía SSO. Y cuando alguien causa baja en el IdP, su cuenta en Drupal queda bloqueada en el siguiente ciclo de sincronización. Esto es oro puro para cumplimiento: el offboarding deja de depender de que alguien se acuerde de cerrar accesos.

Seguridad: MFA y cierre de sesiones

Autenticación multifactor heredada

Aquí está la gracia operativa del SSO. Configuras MFA una sola vez en el IdP y todas las aplicaciones que se conectan, Drupal incluido, heredan esa protección sin tocar nada. Si activas claves físicas FIDO2 o passkeys en el IdP, tu Drupal se beneficia automáticamente.

Single Logout y sesiones

Single Logout (SLO) propaga el cierre de sesión a todas las aplicaciones del ecosistema. Configurarlo en Drupal pide cuidado porque Drupal mantiene sus propias sesiones y hay que sincronizarlas con las del IdP. Tres reglas innegociables: HTTPS en todo el flujo, assertions SAML firmadas digitalmente y, si manejas datos sensibles, también cifradas.

Problemas típicos cuando algo no encaja

Certificados caducados

Es la causa número uno de incidencias en SSO SAML. Un certificado expira sin avisar y de repente nadie entra al portal. Verifica vigencia en ambos lados y revisa la cadena de confianza completa, no solo el certificado de hoja.

Mapeos rotos y bucles de redirección

Si los usuarios aparecen con datos raros, abre las herramientas de debug de SimpleSAMLphp y observa qué atributos llegan realmente del IdP. Los bucles infinitos suelen apuntar a URLs de callback mal configuradas o a problemas con la gestión de cookies de sesión. Revisa también la sincronización horaria vía NTP: SAML rechaza assertions fuera de su ventana de validez y bastan unos segundos de desfase para que todo deje de funcionar.

Cuando tienes varios Drupal

Si gestionas una red de sitios Drupal, puedes compartir una única instalación de SimpleSAMLphp definiendo un Service Provider por sitio. La gestión de sesiones cambia según el escenario: si todos los sitios comparten dominio raíz, las cookies pueden compartirse; si están en dominios diferentes, cada uno necesita su flujo SSO completo. Plantéalo desde el principio porque migrar después es doloroso.

Cumplimiento normativo en España

Los datos que mueves durante la autenticación están sujetos al RGPD. Documenta el tratamiento, su finalidad y la base legal en el registro de actividades. Si tu cliente final es la administración pública o trabajas con ella, el Esquema Nacional de Seguridad (ENS) marca requisitos adicionales sobre fortaleza de autenticación en función de la categoría del sistema. No es opcional y los auditores lo miran.

Mantenimiento que no puedes saltarte

Un SSO no es "lo instalo y me olvido". Pon recordatorios para rotar certificados con margen, mantén Drupal y SimpleSAMLphp al día (las vulnerabilidades en autenticación son siempre críticas) y monta alertas que avisen si el servicio cae o aparecen intentos fallidos fuera de lo normal. Vale más una alerta simple que un postmortem un lunes por la mañana.

Si te toca abordar este proyecto y prefieres no aprender los errores típicos en producción, hablemos para revisar tu infraestructura.

Para cerrar

Montar SSO en Drupal toca tres planos a la vez: protocolos, módulos y requisitos de seguridad empresarial. El coste de hacerlo bien la primera vez se recupera rápido en tickets que desaparecen, en una postura de seguridad más sólida y en una experiencia donde la fricción del login se evapora.

La diferencia entre un SSO que funciona y uno que se vuelve pesadilla está en tres decisiones tempranas: elegir el protocolo correcto, blindar la seguridad desde el primer despliegue y dejar montado el mantenimiento antes de producción. Hazlo así y tu Drupal deja de ser la isla rara del ecosistema corporativo.