shibboleth_auth para TYPO3: Shibboleth Single Sign-On

Cómo las universidades conectan sus portales TYPO3 a la gestión central de identidades

Quien opera un portal TYPO3 en una universidad española no puede ignorar Shibboleth. La Federación Española de Identidad (SIR2) de RedIRIS gestiona la mayor infraestructura de identidad federada del mundo académico e investigador de España, y cualquier universidad que quiera ofrecer datos de investigación, material docente o servicios administrativos al exterior debe autenticar a sus usuarios contra un Identity Provider Shibboleth. shibboleth_auth es la extensión que integra TYPO3 en ese paisaje: lee los atributos que un Shibboleth Service Provider previo extrae de las SAML Assertions, crea sobre esa base fe_users y autentica a los be_users ya existentes.

Escenarios típicos de uso

Una facultad de medicina con 8.000 estudiantes opera un portal TYPO3 para los planes docentes clínicos. Los estudiantes deben ver el material docente tras iniciar sesión, y los profesores, además, una interfaz editorial. El IdP Shibboleth central de la universidad entrega los atributos eduPersonAffiliation, schacHomeOrganization y un identificador unívoco. shibboleth_auth crea grupos de frontend a partir de eduPersonAffiliation y asigna a los usuarios; al backend solo accede quien ya tiene allí una cuenta, por ejemplo un profesor en el grupo de redactores.

Un segundo caso habitual son los centros de investigación extrauniversitarios como el CSIC o institutos conectados a UAM y UCM. Sus trabajadores provienen de docenas de universidades asociadas, y cada uno debe poder iniciar sesión con su identificador de origen en los portales centrales de proyecto. shibboleth_auth, combinado con un SP conectado a eduGAIN, hace justamente eso posible: un investigador invitado desde Zúrich se autentica con su cuenta SWITCHaai en un portal español sin que exista una cuenta local.

El tercer contexto es la administración pública, donde comunidades autónomas y ministerios operan cada vez más IdPs centrales para unificar cuentas ciudadanas y accesos de personal. Un organismo autonómico con varios portales TYPO3 para distintas áreas puede conectar todos los portales al IdP central a través de shibboleth_auth y ahorrarse gestiones de usuarios separadas por portal.

Arquitectura técnica entre SP, SAML y fe_user

shibboleth_auth está construido de forma distinta a los servicios de autenticación clásicos de TYPO3: la extensión no habla SAML directamente, sino que delega el protocolo entero a un Shibboleth Service Provider instalado localmente. El SP, típicamente el demonio shibd con mod_shib en Apache o el módulo correspondiente de Nginx, procesa la SAML Assertion, valida firmas y certificados y expone los atributos extraídos como variables de entorno HTTP. shibboleth_auth lee esas variables, crea o actualiza el fe_user y lo introduce en la sesión de TYPO3.

La extensión se configura mediante la configuración de extensión de TYPO3 y se registra como servicio de autenticación del Core. El mapeo de atributos está en la configuración de la extensión: un ajuste por atributo indica la variable de servidor para identificador, correo, nombre y afiliación. Es importante la prioridad del servicio (ajuste priority, por defecto 100, el servicio de login del Core tiene 50), para que shibboleth_auth actúe antes del servicio de login estándar.

Problemas frecuentes y soluciones

El error más habitual es un bucle de redirección: el usuario es enviado al IdP, vuelve, es enviado de nuevo al IdP, y así sucesivamente. La causa es casi siempre una discrepancia entre el dominio de sesión del SP y el de TYPO3, o una cookie ausente porque el SP escribe su sesión en una ruta diferente a la que TYPO3 espera. La solución es una separación limpia: handlers del SP bajo /Shibboleth.sso antes de cualquier RewriteRule de TYPO3, ambas cookies de sesión bajo / y en el mismo dominio.

El segundo problema afecta a los atributos: el IdP entrega un nombre de atributo distinto al que espera la extensión. Especialmente en federaciones académicas cambian los espacios de nombres de atributos entre notaciones OID y URN. Sin una normalización adecuada, el usuario no acaba en ningún grupo o recibe un nombre vacío en su perfil. Un archivo attribute-map en el SP, que unifica nombres antiguos y nuevos en un nombre local común, resuelve el problema de forma duradera.

El tercer tema es la rotación de certificados. Todo IdP renueva sus certificados de firma y cifrado periódicamente, típicamente cada dos años. El SP debe obtener los nuevos certificados a través del metadata feed, o de lo contrario la validación de la Assertion deja de funcionar de repente. La configuración del metadata provider en shibboleth2.xml debería ejecutarse siempre con un intervalo de refresh automático de pocas horas y con verificación de firma contra el firmante de la federación.

Un cuarto ámbito son las duraciones de sesión. Las sesiones de Shibboleth y TYPO3 tienen timeouts independientes: si la sesión del SP caduca mientras la de TYPO3 sigue activa, el usuario ve sus contenidos protegidos, pero un nuevo login falla porque el SP ya no tiene una Assertion válida. La solución limpia es ajustar ambas duraciones al mismo valor y configurar un comportamiento de logout paralelo, de modo que el Single Logout termine efectivamente ambas sesiones.

Migración y compatibilidad de versiones

En el TER, shibboleth_auth termina con la versión 2.6.5 para TYPO3 6.2; la continúa el fork visol/shibboleth-auth, con versiones para TYPO3 8.7, 10.4, 11.5 y 13.4. No hay una versión propia para TYPO3 v12; solo se mantiene la serie 7.x para v13. Quien migra actualmente a v12 debería comprobar antes del upgrade si el fork que utiliza sigue mantenido o si un cambio a la extensión OIDC es la mejor opción.

La ruta de migración de Shibboleth a OIDC se ha vuelto relevante para muchas universidades desde que Keycloak y brokers de identidad similares pueden conectar clientes SAML y OIDC en paralelo. Gosign ha acompañado varios de esos cambios y opera durante la fase de transición, por regla general, ambos caminos de autenticación en paralelo, de modo que los sistemas legacy siguen iniciando sesión por Shibboleth mientras los nuevos portales hablan OIDC directamente.

Quien permanece en shibboleth_auth a largo plazo debe evaluar de forma realista la carga de mantenimiento. La extensión misma cambia poco, pero la infraestructura que la rodea sí cambia regularmente: Shibboleth SP publica actualizaciones de seguridad, las federaciones académicas actualizan metadatos y certificados, se renuevan versiones de Apache o Nginx, y cada uno de esos cambios puede romper el flujo de login. Una supervisión adecuada del pipeline de autenticación con logins sintéticos y alertas ante Assertions fallidas no es, por tanto, un lujo, sino parte del plan operativo para una integración SSO estable.