shibboleth_auth für TYPO3: Shibboleth Single Sign-On

Wie DFN-AAI-Hochschulen ihre TYPO3-Portale an die zentrale Identitätsverwaltung anschließen

Wer an einer deutschen Universität ein TYPO3-Portal betreibt, kommt an Shibboleth nicht vorbei. Das DFN-Verein-Projekt AAI betreibt die größte Identity-Federation im deutschsprachigen Hochschulraum, und jede Hochschule, die Forschungsdaten, Lehrmaterialien oder Verwaltungsdienste nach außen anbieten will, muss ihre Nutzer gegen einen Shibboleth Identity Provider authentifizieren. shibboleth_auth ist die Extension, die TYPO3 in diese Landschaft einfügt: Sie liest die Attribute aus, die ein vorgeschalteter Shibboleth Service Provider aus den SAML-Assertions gewinnt, legt auf dieser Basis fe_users an und meldet vorhandene be_users an.

Typische Einsatzszenarien

Eine medizinische Fakultät mit 8.000 Studierenden betreibt ein TYPO3-Portal für klinische Curricula. Studierende sollen ihre Lehrmaterialien nach Login sehen, Dozenten zusätzlich eine Redaktionsoberfläche. Der zentrale Shibboleth-IdP der Universität liefert die Attribute eduPersonAffiliation, schacHomeOrganization und eine eindeutige Kennung. shibboleth_auth legt aus eduPersonAffiliation Frontend-Gruppen an und ordnet die Nutzer zu; ins Backend kommt nur, wer dort schon ein Konto hat, etwa ein Dozent in der Redakteursgruppe.

Ein zweiter typischer Fall sind außeruniversitäre Forschungseinrichtungen wie Max-Planck-Institute oder Fraunhofer-Gesellschaften. Ihre Mitarbeiter stammen aus Dutzenden Partnerhochschulen, und jeder soll sich mit seiner Heimat-Kennung an zentralen Projektportalen anmelden können. shibboleth_auth in Verbindung mit einem eduGAIN-angebundenen SP macht genau das möglich: Ein Gastforscher aus Zürich meldet sich mit seinem SWITCHaai-Account an einem deutschen Portal an, ohne dass ein lokaler Account existieren muss.

Der dritte Kontext ist die öffentliche Verwaltung, wo Bundesländer zunehmend landesweite IdPs betreiben, um Bürgerkonten und Mitarbeiter-Zugänge zu bündeln. Eine Landesbehörde mit mehreren TYPO3-Portalen für verschiedene Fachbereiche kann über shibboleth_auth alle Portale an den zentralen IdP des Landes anbinden und spart sich separate Benutzerverwaltungen je Portal.

Technische Architektur zwischen SP, SAML und fe_user

shibboleth_auth ist anders gebaut als klassische TYPO3-Auth-Services: Die Extension spricht nicht direkt SAML, sondern delegiert das gesamte Protokoll an einen lokal installierten Shibboleth Service Provider. Der SP, typischerweise der shibd-Daemon mit mod_shib im Apache oder dem entsprechenden Nginx-Modul, verarbeitet die SAML-Assertion, validiert Signaturen und Zertifikate und stellt die extrahierten Attribute als HTTP-Umgebungsvariablen bereit. shibboleth_auth liest diese Variablen, erzeugt oder aktualisiert den fe_user und loggt ihn in die TYPO3-Session ein.

Konfiguriert wird die Extension über die TYPO3-Extension-Konfiguration; sie meldet sich als Authentifizierungs-Service des Core an. Das Attribut-Mapping liegt in der Extension-Konfiguration: Je eine Einstellung nennt die Server-Variable für Kennung, E-Mail, Namen und Affiliation. Wichtig ist die Priorität des Services (Einstellung priority, Standard 100, der Login-Service des Core hat 50), damit shibboleth_auth vor dem Standard-Login-Service greift.

Häufige Probleme und Lösungen

Der häufigste Fehler ist ein Redirect-Loop: Der Nutzer wird zum IdP geschickt, kommt zurück, wird erneut zum IdP geschickt, und so weiter. Ursache ist fast immer eine Diskrepanz zwischen der Session-Domain des SP und der von TYPO3, oder ein fehlendes Cookie, weil der SP seine Session unter einem anderen Pfad schreibt als TYPO3 erwartet. Die Lösung ist eine saubere Trennung: Handler des SP unter /Shibboleth.sso vor jeder TYPO3-RewriteRule, beide Session-Cookies unter / und derselben Domain.

Das zweite Problem betrifft Attribute: Der IdP liefert einen anderen Attributnamen, als die Extension erwartet. Besonders bei DFN-AAI ändern sich Attribut-Namensräume zwischen OID- und URN-Schreibweisen. Ohne saubere Normalisierung landet der Nutzer in keiner Gruppe oder bekommt einen leeren Namen ins Profil geschrieben. Eine Attribute-Map-Datei im SP, die alte und neue Namen auf einen einheitlichen lokalen Namen zusammenführt, löst das Problem dauerhaft.

Das dritte Thema ist Zertifikats-Rollover. Jeder IdP tauscht seine Signing- und Encryption-Zertifikate regelmäßig aus, typischerweise alle zwei Jahre. Der SP muss die neuen Zertifikate über den Metadaten-Feed ziehen, sonst bricht die Assertion-Validierung plötzlich ab. Die Metadaten-Provider-Konfiguration im shibboleth2.xml sollte daher immer mit einem automatischen Refresh-Intervall von wenigen Stunden und einer Signatur-Prüfung gegen den Federation-Signer laufen.

Ein viertes Problemfeld sind Session-Lifetimes. Shibboleth- und TYPO3-Sessions haben voneinander unabhängige Timeouts: Läuft die SP-Session ab, während die TYPO3-Session noch aktiv ist, sieht der Nutzer zwar seine geschützten Inhalte, aber ein Neu-Login schlägt fehl, weil der SP keine gültige Assertion mehr hat. Die saubere Lösung ist, beide Session-Dauern auf denselben Wert zu setzen und ein paralleles Logout-Verhalten zu konfigurieren, sodass Single Logout tatsächlich beide Sessions beendet.

Migration und Versions-Kompatibilität

shibboleth_auth endet im TER mit Version 2.6.5 bei TYPO3 6.2; weitergeführt hat sie der Fork visol/shibboleth-auth, mit Versionen für TYPO3 8.7, 10.4, 11.5 und 13.4. Eine eigene Version für TYPO3 v12 gibt es nicht, gepflegt wird nur die Reihe 7.x für v13. Wer aktuell auf v12 migriert, sollte vor dem Upgrade prüfen, ob der eigene Extension-Zweig noch gepflegt wird oder ein Wechsel auf die OIDC-Extension die bessere Wahl ist.

Der Migrationspfad von Shibboleth zu OIDC ist für viele Hochschulen relevant geworden, seit Keycloak und vergleichbare Identity-Broker SAML- und OIDC-Clients parallel anbinden können. Gosign hat solche Übergänge mehrfach begleitet und betreibt während der Umstellungsphase in der Regel beide Auth-Pfade parallel, sodass Legacy-Systeme weiter über Shibboleth anmelden, während neue Portale direkt OIDC sprechen.

Wer dauerhaft bei shibboleth_auth bleibt, sollte den Wartungs-Aufwand realistisch einschätzen. Die Extension selbst ändert sich selten, die umgebende Infrastruktur aber regelmäßig: Shibboleth SP veröffentlicht Security-Updates, DFN-AAI aktualisiert Metadaten und Zertifikate, Apache- oder Nginx-Versionen werden ausgetauscht, und jede dieser Änderungen kann den Login-Fluss brechen. Eine saubere Überwachung der Auth-Pipeline mit synthetischen Logins und Alerts bei fehlgeschlagenen Assertions ist daher kein Nice-to-have, sondern Teil des Betriebskonzepts für eine stabile SSO-Integration.