Shibboleth für TYPO3

Hochschulen und Forschungseinrichtungen brauchen Shibboleth-SSO direkt in TYPO3

Im akademischen Sektor ist Shibboleth der De-facto-Standard für Single Sign-On. Über 3.000 Einrichtungen weltweit sind in Shibboleth-Föderationen organisiert, in Deutschland über den DFN-AAI-Verbund mit über 700 teilnehmenden Organisationen. Die Shibboleth-Extension für TYPO3 integriert den Service Provider direkt ins CMS. Studierende, Dozierende und Mitarbeitende melden sich mit ihrer Hochschulkennung an und erhalten Zugang zu geschützten Frontend-Bereichen und bei Bedarf zum TYPO3-Backend. Die Extension ist die Schwester von shibboleth_auth und bietet die Basis-Integration für den Shibboleth SP, der auf dem Webserver installiert sein muss.

Im Gegensatz zur saml2-Extension, die einen eigenen SP in PHP implementiert, setzt die shibboleth-Extension auf den nativen Shibboleth Service Provider (C++ oder Java), der als Apache-Modul oder ISAPI-Filter läuft. Das ist die robustere Architektur für Hochverfügbarkeitsumgebungen.

Typische Einsatzszenarien betreffen DFN-AAI, Bibliothekssysteme und Forschungsportale

Das primäre Szenario ist die DFN-AAI-Integration an deutschen Hochschulen. Eine Universität betreibt ihr Webportal auf TYPO3. Studierende klicken auf “Login”, werden zum IdP der Hochschule weitergeleitet, authentifizieren sich und landen zurück auf der TYPO3-Seite mit einer aktiven Session. Die Extension liest die Shibboleth-Attribute aus den Server-Umgebungsvariablen (REMOTE_USER, eppn, mail, affiliation) und erstellt oder aktualisiert den TYPO3-Frontend-User.

Ein zweites Szenario sind Bibliotheks-Zugänge. Hochschulbibliotheken bieten Online-Datenbanken, E-Journals und Forschungsdokumente über ihre TYPO3-Website an. Der Zugang ist auf Hochschulangehörige beschränkt. Die Shibboleth-Extension prüft das Attribut “eduPersonEntitlement” und gewährt nur Nutzern mit dem Wert “urn:mace:dir:entitlement:common-lib-terms” Zugang zu lizenzierten Inhalten.

Drittes Szenario: Föderierte Forschungsportale. Ein Forschungskonsortium mit Partnern aus fünf Universitäten betreibt ein gemeinsames Portal auf TYPO3. Jeder Partner hat seinen eigenen IdP. Über die DFN-AAI-Föderation können alle Partner-Mitarbeitenden sich anmelden, ohne dass das Portal eigene Accounts verwalten muss. Die Extension ordnet die Nutzer basierend auf dem Attribut “schacHomeOrganization” der richtigen Partner-Gruppe zu.

Technische Architektur setzt einen installierten Shibboleth SP auf dem Webserver voraus

Die Extension selbst enthält keinen SAML-Stack. Sie liest die Attribute, die der Shibboleth SP nach erfolgreicher Authentifizierung als Server-Umgebungsvariablen oder HTTP-Header bereitstellt. Der SP muss als Apache-Modul (mod_shib) oder als FastCGI-Authorizer konfiguriert sein. Für nginx-Setups ist ein Shibboleth SP als FastCGI-Backend oder ein lua-basierter Proxy nötig.

Die TYPO3-Extension registriert einen Authentication Service, der bei jedem Frontend- oder Backend-Login prüft, ob Shibboleth-Attribute vorhanden sind. Wenn ja, werden die Attribute auf TYPO3-User-Felder gemappt: REMOTE_USER auf username, mail auf email, givenName und sn auf first_name und last_name. Die Gruppenzuordnung erfolgt über das Attribut “eduPersonAffiliation”: student, faculty, staff, employee werden auf TYPO3-Frontend-Gruppen gemappt.

Die Session-Verwaltung folgt dem Shibboleth-Lifecycle: Wenn die Shibboleth-Session abläuft, wird der TYPO3-User automatisch ausgeloggt. Single Logout (SLO) wird über den Shibboleth SP abgewickelt, die TYPO3-Extension reagiert auf das Logout-Event und zerstört die TYPO3-Session.

Häufige Probleme betreffen die Apache-Konfiguration und fehlende Attribute

Das grösste Problem ist die korrekte Apache-Konfiguration. Der Shibboleth SP muss wissen, welche URLs er schützen soll. Eine falsche Location-Direktive führt dazu, dass der SP entweder alle Seiten schützt (auch öffentliche) oder gar keine. Die Standard-Konfiguration schützt /Shibboleth.sso/* für den SP selbst und /typo3/ für das Backend. Frontend-Bereiche werden per Lazy Session geschützt: Der SP setzt Attribute, wenn eine Shibboleth-Session existiert, erzwingt aber keine Authentifizierung. Die Extension prüft dann im TYPO3-Frontend, ob Attribute vorhanden sind, und zeigt geschützte Inhalte nur angemeldeten Nutzern.

Zweites Problem: Fehlende oder leere Attribute. Nicht jeder IdP liefert alle Attribute. Wenn der IdP das Attribut “mail” nicht freigibt, kann die Extension keine E-Mail-Adresse in den TYPO3-User schreiben. Die Lösung: Mit dem IdP-Betreiber (Rechenzentrum) klären, welche Attribute für den SP freigegeben sind, und das Attribute-Mapping in der Extension entsprechend konfigurieren.

Drittes Thema: Container-Deployments. Docker-basierte TYPO3-Installationen haben oft keinen Apache mit mod_shib. Die Alternative ist ein Shibboleth SP als Reverse Proxy vor dem TYPO3-Container, der die Attribute als HTTP-Header weiterleitet. Die Extension muss dann so konfiguriert werden, dass sie Attribute aus Headern statt aus Umgebungsvariablen liest. Wichtig: Die Header müssen vor Spoofing geschützt werden, indem der Reverse Proxy eingehende Header mit Shibboleth-Attributnamen entfernt.

TYPO3 v12 funktioniert, v13-Kompatibilität erfordert eine Prüfung der Authentication-Service-API

Die shibboleth-Extension nutzt die TYPO3 Authentication Service API, die seit Jahren stabil ist, aber in v13 Anpassungen erfahren hat. Unter TYPO3 v12 läuft die aktuelle Version ohne Probleme. Für v13 ist ein Update der Service-Registrierung und der Middleware-Konfiguration nötig. Hochschulen, die TYPO3-Upgrades planen, sollten die SSO-Integration als eigenen Testblock in die Upgrade-Planung aufnehmen. Gosign empfiehlt, parallel zur shibboleth-Extension die oidc-Extension zu evaluieren, weil viele IdPs inzwischen sowohl SAML als auch OIDC unterstützen und OIDC die einfachere Architektur ohne Shibboleth SP auf dem Server ermöglicht.