shibboleth_auth for TYPO3: Shibboleth Single Sign-On

How universities connect their TYPO3 portals to central identity management

Anyone running a TYPO3 portal at a European research university cannot avoid Shibboleth. National research network federations such as DFN-AAI in Germany, SWITCHaai in Switzerland or eduGAIN across Europe operate the largest identity federations in the academic space, and every university that wants to offer research data, teaching materials or administrative services to the outside world has to authenticate its users against a Shibboleth Identity Provider. shibboleth_auth is the extension that plugs TYPO3 into this landscape: it reads the SAML assertions provided by an upstream Shibboleth Service Provider and uses them to create fe_users and be_users.

Typical use cases

A medical faculty with 8,000 students runs a TYPO3 portal for clinical curricula. Students should see their teaching materials after login, while lecturers additionally get an editorial interface. The university’s central Shibboleth IdP delivers attributes such as eduPersonAffiliation, schacHomeOrganization and a unique identifier. shibboleth_auth handles the mapping of these attributes onto TYPO3 groups and ensures that a student never reaches the backend, while a lecturer automatically lands in the editor group.

A second typical case is non-university research institutions such as Max Planck Institutes or Fraunhofer centres. Their staff come from dozens of partner universities, and each researcher should be able to log in to shared project portals using their home credentials. shibboleth_auth combined with an eduGAIN-connected SP makes exactly that possible: a visiting researcher from Zurich logs in with their SWITCHaai account on a German portal, without any local account having to exist.

The third context is public administration, where regional governments increasingly run statewide IdPs to consolidate citizen accounts and staff logins. A state authority with several TYPO3 portals for different departments can connect them all through shibboleth_auth to the central state IdP and avoid maintaining separate user databases per portal.

Technical architecture between SP, SAML and fe_user

shibboleth_auth is built differently from classic TYPO3 auth services: the extension does not speak SAML directly but delegates the entire protocol to a locally installed Shibboleth Service Provider. The SP, typically the shibd daemon with mod_shib in Apache or the corresponding Nginx module, processes the SAML assertion, validates signatures and certificates and exposes the extracted attributes as HTTP environment variables. shibboleth_auth reads these variables, creates or updates the fe_user and logs them into the TYPO3 session.

The extension is configured through the TYPO3 extension configuration and the Extbase service pattern for auth providers. Attribute mapping lives in a TypoScript file or directly in the extension backend: HTTP variable on the left, TYPO3 field name on the right, optionally with transformations for group IDs. The order in the $TYPO3_CONF_VARS[‘SVCONF’][‘auth’][‘setup’] configuration matters, so that shibboleth_auth kicks in before the default login service.

Common problems and solutions

The most common failure is a redirect loop: the user is sent to the IdP, returns, is sent to the IdP again, and so on. The cause is almost always a mismatch between the SP session domain and TYPO3’s, or a missing cookie because the SP writes its session under a different path than TYPO3 expects. The clean solution is a strict separation: SP session under the path /Shibboleth.sso, TYPO3 session under / and both under the same top-level domain.

The second issue involves attributes: the IdP delivers a different attribute name than the extension expects. Especially in DFN-AAI, attribute namespaces shift between OID and URN notation. Without clean normalisation, the user ends up in no group at all or gets an empty name written into their profile. An attribute map file on the SP that folds old and new names onto a single local name resolves the problem permanently.

The third topic is certificate rollover. Every IdP regularly rotates its signing and encryption certificates, typically every two years. The SP has to pull the new certificates via the metadata feed, otherwise assertion validation suddenly breaks. The metadata provider configuration in shibboleth2.xml should therefore always run with an automatic refresh interval of a few hours and with signature verification against the federation signer.

A fourth problem area is session lifetimes. Shibboleth and TYPO3 sessions have timeouts that are independent of each other: if the SP session expires while the TYPO3 session is still active, the user can still see their protected content, but a fresh login fails because the SP no longer has a valid assertion. The clean solution is to set both session durations to the same value and to configure a parallel logout behaviour, so that Single Logout actually ends both sessions.

Migration and version compatibility

shibboleth_auth has followed TYPO3 v9, v10 and v11 for a long time through community forks, but the situation in v12 and v13 varies depending on the fork branch. Some forks have moved to Symfony-based auth services, others have stopped at v11. Anyone migrating to v12 today should check before the upgrade whether their extension branch is still maintained or whether switching to the OIDC extension is the better choice.

The migration path from Shibboleth to OIDC has become relevant for many universities since Keycloak and similar identity brokers can serve SAML and OIDC clients in parallel. Gosign has accompanied such transitions several times and typically runs both auth paths side by side during the switchover, so that legacy systems keep logging in via Shibboleth while new portals speak OIDC directly.

Anyone planning to stay on shibboleth_auth permanently should assess the maintenance overhead realistically. The extension itself rarely changes, but the surrounding infrastructure does: Shibboleth SP releases security updates, federations update metadata and certificates, Apache or Nginx versions are replaced, and any one of these changes can break the login flow. Clean monitoring of the auth pipeline with synthetic logins and alerts on failed assertions is therefore not a nice-to-have but part of the operational model for a stable SSO integration.