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 mit SimpleSAMLphp einen SP in PHP nutzt, setzt die shibboleth-Extension auf den nativen Shibboleth Service Provider (in C++ geschrieben), der als Apache-Modul oder als natives IIS-Modul 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ößte 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.

Die shibboleth-Extension endet bei TYPO3 8.7

Die shibboleth-Extension nutzt die TYPO3 Authentication Service API. Ihre letzte Version 3.1.7 ist im Oktober 2018 erschienen und unterstützt TYPO3 7.6 bis 8.7; für neuere TYPO3-Versionen gibt es kein Release, auch nicht im GitHub-Repository des Autors. 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.