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 las SAML Assertions de un Shibboleth Service Provider en cascada y crea sobre esa base fe_users y be_users.

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 se encarga del mapeo de esos atributos a grupos TYPO3 y garantiza que un estudiante nunca acceda al backend, mientras que un profesor acaba automáticamente 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 el patrón de servicios Extbase para proveedores de autenticación. El mapeo de atributos está en un fichero TypoScript o directamente en el backend de la extensión: variable HTTP a la izquierda, nombre del campo TYPO3 a la derecha, opcionalmente con transformaciones para IDs de grupo. Es importante el orden en la configuración $TYPO3_CONF_VARS[‘SVCONF’][‘auth’][‘setup’], 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: sesión del SP en la ruta /Shibboleth.sso, sesión de TYPO3 bajo / y ambas bajo el mismo dominio de primer nivel.

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

shibboleth_auth acompañó durante mucho tiempo, mediante forks comunitarios, a las versiones de TYPO3 v9, v10 y v11. La situación en v12 y v13 difiere según la rama del fork. Algunas ramas han dado el salto a servicios de autenticación basados en Symfony, otras se han quedado en v11. 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.