Shibboleth para TYPO3

Universidades y centros de investigación necesitan SSO Shibboleth directamente en TYPO3

En el sector académico, Shibboleth es el estándar de facto para Single Sign-On. Más de 3.000 instituciones en todo el mundo están organizadas en federaciones Shibboleth; en España, SIR2 (Servicio de Identidad de RedIRIS) agrupa a decenas de universidades y centros de investigación. La extensión Shibboleth para TYPO3 integra el Service Provider directamente en el CMS. Estudiantes, docentes y personal se autentican con sus credenciales universitarias y obtienen acceso a áreas de frontend protegidas y, en caso necesario, al backend de TYPO3. La extensión es la hermana de shibboleth_auth y ofrece la integración básica con el SP Shibboleth, que debe estar instalado en el servidor web.

A diferencia de la extensión saml2, que implementa su propio SP en PHP, la extensión shibboleth se apoya en el Service Provider nativo de Shibboleth (C++ o Java), que funciona como módulo de Apache o filtro ISAPI. Es la arquitectura más robusta para entornos de alta disponibilidad.

Los escenarios típicos afectan a SIR2, sistemas bibliotecarios y portales de investigación

El escenario principal es la integración SIR2 en universidades españolas. Una universidad opera su portal web sobre TYPO3. Los estudiantes pulsan “Iniciar sesión”, son redirigidos al IdP de la universidad, se autentican y regresan a la página TYPO3 con una sesión activa. La extensión lee los atributos Shibboleth desde las variables de entorno del servidor (REMOTE_USER, eppn, mail, affiliation) y crea o actualiza el usuario de frontend en TYPO3.

Un segundo escenario son los accesos bibliotecarios. Las bibliotecas universitarias ofrecen bases de datos en línea, revistas electrónicas y documentos de investigación a través de su sitio TYPO3. El acceso queda limitado a miembros de la universidad. La extensión Shibboleth comprueba el atributo “eduPersonEntitlement” y solo concede acceso al contenido licenciado a los usuarios con el valor “urn:mace:dir:entitlement:common-lib-terms”.

Tercer escenario: portales de investigación federados. Un consorcio de investigación con socios de cinco universidades opera un portal conjunto sobre TYPO3. Cada socio tiene su propio IdP. A través de SIR2 o eduGAIN, todo el personal de los socios puede autenticarse sin que el portal tenga que gestionar cuentas propias. La extensión asigna a los usuarios al grupo de socio correcto basándose en el atributo “schacHomeOrganization”.

La arquitectura técnica requiere un SP Shibboleth instalado en el servidor web

La propia extensión no contiene pila SAML. Lee los atributos que el SP Shibboleth pone a disposición como variables de entorno del servidor o cabeceras HTTP tras una autenticación satisfactoria. El SP debe estar configurado como módulo de Apache (mod_shib) o como FastCGI Authorizer. Para entornos nginx se necesita un SP Shibboleth como backend FastCGI o un proxy basado en lua.

La extensión TYPO3 registra un Authentication Service que, en cada inicio de sesión de frontend o backend, comprueba si existen atributos Shibboleth. Si los hay, los atributos se mapean a campos del usuario TYPO3: REMOTE_USER a username, mail a email, givenName y sn a first_name y last_name. La asignación de grupos se hace mediante el atributo “eduPersonAffiliation”: student, faculty, staff, employee se mapean a grupos de frontend TYPO3.

La gestión de sesiones sigue el ciclo de vida de Shibboleth: cuando la sesión Shibboleth expira, el usuario TYPO3 se desconecta automáticamente. El Single Logout (SLO) lo gestiona el SP Shibboleth; la extensión TYPO3 reacciona al evento de logout y destruye la sesión TYPO3.

Los problemas habituales afectan a la configuración de Apache y a atributos ausentes

El mayor problema es una configuración correcta de Apache. El SP Shibboleth debe saber qué URLs debe proteger. Una directiva Location mal definida hace que el SP proteja todas las páginas (incluyendo las públicas) o ninguna. La configuración estándar protege /Shibboleth.sso/* para el propio SP y /typo3/ para el backend. Las áreas de frontend se protegen mediante Lazy Session: el SP asigna atributos cuando existe una sesión Shibboleth, pero no fuerza la autenticación. La extensión comprueba entonces en el frontend TYPO3 si existen atributos y muestra el contenido protegido solo a los usuarios autenticados.

Segundo problema: atributos ausentes o vacíos. No todos los IdPs entregan todos los atributos. Si el IdP no libera el atributo “mail”, la extensión no puede escribir ninguna dirección de correo en el usuario TYPO3. La solución: aclarar con el responsable del IdP (el centro de cálculo) qué atributos se liberan para el SP y configurar el mapeo de atributos en consecuencia.

Tercer tema: despliegues en contenedores. Las instalaciones TYPO3 basadas en Docker a menudo no tienen Apache con mod_shib. La alternativa es un SP Shibboleth como proxy inverso delante del contenedor TYPO3, que reenvía los atributos como cabeceras HTTP. La extensión debe configurarse entonces para leer los atributos desde cabeceras en lugar de variables de entorno. Importante: las cabeceras deben protegerse frente a spoofing, eliminando en el proxy inverso cualquier cabecera entrante que use nombres de atributos Shibboleth.

TYPO3 v12 funciona, la compatibilidad con v13 exige revisar la API de Authentication Service

La extensión shibboleth utiliza la TYPO3 Authentication Service API, que lleva años estable pero que en v13 ha recibido ajustes. Bajo TYPO3 v12 la versión actual funciona sin problemas. Para v13 hace falta una actualización del registro del servicio y de la configuración del middleware. Las universidades que planifican upgrades de TYPO3 deberían incluir la integración SSO como bloque de pruebas propio en la planificación del upgrade. Gosign recomienda evaluar en paralelo a shibboleth la extensión oidc, porque muchos IdPs soportan hoy en día tanto SAML como OIDC, y OIDC permite una arquitectura más sencilla sin SP Shibboleth en el servidor.