Shibboleth for TYPO3

Universities and research institutions need Shibboleth SSO directly in TYPO3

In the academic sector, Shibboleth is the de facto standard for single sign-on. More than 3,000 institutions worldwide are organized in Shibboleth federations. In Germany, the DFN-AAI federation alone has more than 700 participating organizations, and eduGAIN links the national federations with one another. The Shibboleth extension for TYPO3 integrates the service provider directly into the CMS. Students, lecturers and staff sign in with their university credentials and gain access to protected frontend areas and, where needed, to the TYPO3 backend. The extension is the sister of shibboleth_auth and provides the base integration for the Shibboleth SP, which has to be installed on the web server.

Unlike the saml2 extension, which uses SimpleSAMLphp as an SP written in PHP, the shibboleth extension relies on the native Shibboleth service provider (written in C++), running as an Apache module or a native IIS module. For high-availability environments, this is the more robust architecture.

Typical use cases involve research federations, library systems and research portals

The primary scenario is integration with the national research and education federation, which at German universities means the DFN-AAI. A university runs its web portal on TYPO3. Students click “Login”, are redirected to their university’s IdP, authenticate and land back on the TYPO3 page with an active session. The extension reads the Shibboleth attributes from the server environment variables (REMOTE_USER, eppn, mail, affiliation) and creates or updates the TYPO3 frontend user.

A second scenario is library access. University libraries offer online databases, e-journals and research documents through their TYPO3 website, with access restricted to members of the university. The Shibboleth extension checks the attribute “eduPersonEntitlement” and grants access to licensed content only to users with the value “urn:mace:dir:entitlement:common-lib-terms”.

The third scenario is federated research portals. A research consortium with partners from five universities runs a shared portal on TYPO3, and each partner has its own IdP. Through the federation (in Germany, the DFN-AAI; for partners in other countries, eduGAIN), all partner staff can sign in without the portal having to manage accounts of its own. The extension assigns users to the right partner group based on the attribute “schacHomeOrganization”.

The technical architecture requires a Shibboleth SP installed on the web server

The extension itself contains no SAML stack. It reads the attributes that the Shibboleth SP provides as server environment variables or HTTP headers after successful authentication. The SP must be configured as an Apache module (mod_shib) or as a FastCGI authorizer. nginx setups need a Shibboleth SP as a FastCGI backend or a Lua-based proxy.

The TYPO3 extension registers an authentication service that checks at every frontend or backend login whether Shibboleth attributes are present. If they are, the attributes are mapped to TYPO3 user fields: REMOTE_USER to username, mail to email, givenName and sn to first_name and last_name. Group assignment uses the attribute “eduPersonAffiliation”: student, faculty, staff and employee are mapped to TYPO3 frontend groups.

Session management follows the Shibboleth lifecycle: when the Shibboleth session expires, the TYPO3 user is logged out automatically. Single logout (SLO) is handled by the Shibboleth SP, and the TYPO3 extension responds to the logout event by destroying the TYPO3 session.

Common problems involve the Apache configuration and missing attributes

The biggest problem is getting the Apache configuration right. The Shibboleth SP needs to know which URLs it should protect. A wrong Location directive means the SP either protects every page (public ones included) or none at all. The standard configuration protects /Shibboleth.sso/* for the SP itself and /typo3/ for the backend. Frontend areas are protected with a lazy session: the SP sets attributes if a Shibboleth session exists but does not force authentication. The extension then checks in the TYPO3 frontend whether attributes are present and shows protected content only to signed-in users.

The second problem is missing or empty attributes. Not every IdP releases every attribute. If the IdP does not release the attribute “mail”, the extension cannot write an email address into the TYPO3 user. The fix: clarify with the IdP operator (usually the university’s IT center) which attributes are released to the SP, and configure the attribute mapping in the extension accordingly.

The third topic is container deployments. Docker-based TYPO3 installations often have no Apache with mod_shib. The alternative is a Shibboleth SP acting as a reverse proxy in front of the TYPO3 container, forwarding the attributes as HTTP headers. The extension then has to be configured to read attributes from headers instead of environment variables. Important: the headers must be protected against spoofing, with the reverse proxy stripping any incoming headers that carry Shibboleth attribute names.

The shibboleth extension ends at TYPO3 8.7

The shibboleth extension uses the TYPO3 authentication service API. Its last version, 3.1.7, was released in October 2018 and supports TYPO3 7.6 to 8.7; there is no release for newer TYPO3 versions, not even in the author’s GitHub repository. Universities planning TYPO3 upgrades should include the SSO integration as a separate test block in their upgrade plan. Gosign recommends evaluating the oidc extension alongside the shibboleth extension, because many IdPs now support both SAML and OIDC, and OIDC allows a simpler architecture without a Shibboleth SP on the server.