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 SAML-Assertions eines vorgeschalteten Shibboleth Service Providers aus und legt auf dieser Basis fe_users und 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 übernimmt das Mapping dieser Attribute auf TYPO3-Gruppen und sorgt dafür, dass ein Student nie ins Backend kommt, während ein Dozent automatisch in der Redakteursgruppe landet.

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 und das Extbase-Service-Pattern für Auth-Provider. Das Attribut-Mapping liegt in einer TypoScript-Datei oder direkt im Extension-Backend: HTTP-Variable links, TYPO3-Feldname rechts, optional mit Transformationen für Gruppen-IDs. Wichtig ist die Reihenfolge in der $TYPO3_CONF_VARS[‘SVCONF’][‘auth’][‘setup’]-Konfiguration, 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: SP-Session im Pfad /Shibboleth.sso, TYPO3-Session unter / und beide unter derselben Top-Level-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 hat die TYPO3-Versionen v9, v10 und v11 über Community-Forks lange Zeit begleitet, die Situation in v12 und v13 ist jedoch unterschiedlich je nach Fork-Zweig. Einige Forks haben den Sprung auf Symfony-basierte Auth-Services vollzogen, andere sind auf v11 stehen geblieben. 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.