Single Sign-On
Eine Produktivinstanz
Single Sign-On für TYPO3 — dein Identity Provider, deine Regeln
Deine Organisation hat längst entschieden, wer sich wo anmelden darf. Nur TYPO3 hat die Nachricht nie bekommen.
Single Sign-On macht TYPO3 zu einem SAML-2.0-Service-Provider. Die Anmeldung von Redakteuren und Frontend-Benutzern läuft dann über Microsoft Entra ID, Keycloak, ADFS oder was auch immer bei dir im Einsatz ist — und TYPO3 akzeptiert die Assertion statt eines Passworts. Ein- und Austritte sowie die Passwortrichtlinie bleiben da, wo sie ohnehin geregelt sind.
Das Problem
Jede TYPO3-Installation führt ihre eigene Liste, wer existiert, und hat ihre eigene Vorstellung davon, was ein gutes Passwort ist. Das ist eine Liste mehr, als deine Organisation haben will.
Jemand geht, das Konto bleibt. Der Verzeichniseintrag ist noch am selben Nachmittag deaktiviert, die Zeile in be_users nicht — weil außerhalb des Projekts niemand weiß, dass es sie gibt. Beim nächsten Audit ist sie immer noch da, und sie ist der Befund, der sich am schwersten erklären lässt.
Deine Passwortrichtlinie endet vor dem CMS. Wechselintervall, Mindestlänge, ein zweiter Faktor — all das setzt dein Identity Provider durch, und nichts davon erreicht TYPO3. Das hat seine eigenen Regeln und seine eigene Mail zum Zurücksetzen.
Jeder Redakteur schleppt ein Passwort mehr mit sich herum. Für sich genommen das kleinste Problem — aber es ist genau das eine, das vergessen wird, und das Zurücksetzen landet bei dem, der die Website pflegt.
Und die Agentur hat auch noch einen Zugang. Wer die Website gebaut hat, hat eine Anmeldung, die das Projekt überlebt, solange sich niemand daran erinnert, sie zu entfernen.
Nichts davon ist ein Fehler in TYPO3. Es ist das, was passiert, wenn eine Anwendung ihre eigenen Benutzer führt, während die Organisation alle anderen woanders verwaltet.
So funktioniert es
TYPO3 wird zum Service Provider. Du meldest es einmal bei deinem Identity Provider an, zeigst der Extension die Metadaten des Providers, und der Anmeldebildschirm bekommt einen Eintrag neben dem gewohnten.
Backend und Frontend sind getrennte Service Provider. Jedes hat seine eigene Entity ID, seine eigene Konfiguration und sein eigenes Zertifikat — und beide funktionieren ohne das andere. Redakteure können sich über das Firmenverzeichnis anmelden, während das Frontend bei seiner eigenen Anmeldung bleibt, oder umgekehrt, oder beide gegen verschiedene Provider. Das Frontend wird pro Site konfiguriert.
Die Abmeldung gilt überall. Ein Single-Logout-Request beendet die Sitzung auf beiden Seiten, nicht nur die lokale.
Solange du nichts einrichtest, ändert sich nichts. Die Extension allein lässt jeden Anmeldebildschirm genau so, wie er war. Die Umstellung ist eine bewusste Entscheidung, getrennt für Backend und Frontend.
Was du bekommst
Die Kontenfrage, beantwortet, bevor sie jemand stellt
Federation — also das Anlegen des TYPO3-Benutzers aus der Assertion — ist in beiden Bereichen standardmäßig aus, und aus ist die sichere Einstellung: Eine Identität, die dein Provider anmeldet, für die es in TYPO3 aber keinen Benutzer gibt, wird abgewiesen, und die Abweisung wird protokolliert. Niemand bekommt ein Konto, nur weil er vorbeikommt.
Schalte Federation ein, wenn alle Benutzer eines Mandanten Zugang haben sollen. Lass sie aus, wo dein Provider das ganze Unternehmen bedient und nur ein Teil davon ins CMS gehört — oder grenze sie mit einem Listener auf BeforeUserCreationEvent ein und entscheide in deinem eigenen Code, wer hereinkommt.
Ein Weg zurück, immer
Das Install Tool bleibt mit eigenen Zugangsdaten erreichbar, unabhängig von SSO. Ist der Provider nicht erreichbar, laufen die Metadaten ab oder wird ein Zertifikat im falschen Moment getauscht, sperrst du dich nicht aus deinem eigenen CMS aus. Das ist die erste Frage jedes Betriebsteams, und die Antwort lautet nicht „ruf uns an“.
Gruppen aus Claims, nicht aus einer gepflegten Liste
Die Gruppenzugehörigkeit kann den Claims folgen, die dein Provider mitschickt. Damit wird die Frage „wer darf welchen Bereich bearbeiten“ in dem Verzeichnis beantwortet, das deine Organisation ohnehin pflegt. Ändere dort eine Gruppe, und die nächste Anmeldung bringt die Änderung mit.
Abgewiesene Anmeldungen sind sichtbar
Jede abgelehnte Anmeldung landet im sys_log, die technischen Details im PSR-3-Logger. Sagt jemand „ich komme nicht rein“, findest du den Grund in dem System, das du ohnehin überwachst, statt den Fall nachzustellen.
Es läuft in der Umgebung, die du hast
Hinter TLS-Terminierung, hinter einem Reverse Proxy, mit der Konfiguration, die die Prüfung der Assertion funktionieren lässt — statt sie so scheitern zu lassen, dass es nach einem Problem mit den Zugangsdaten aussieht. Zertifikate und Provider-URLs stehen in Umgebungsvariablen. Dieselbe Codebasis bedient damit Entwicklung, Staging und Produktion gegen verschiedene Provider.
Dein eigener Code redet mit
Zwei PSR-14-Events sitzen an den beiden Stellen, auf die es ankommt: bevor ein Benutzer angelegt wird, und bevor seine Daten aus der Assertion aktualisiert werden. Einen ungewöhnlichen Claim zuordnen, eine Gruppe aussperren, ein Feld schützen, das deinem Projekt gehört — ohne Fork.
Im Vergleich zu heute
|
TYPO3 im Auslieferungszustand
|
Single Sign-On
|
|
|---|---|---|
| Wem die Benutzerliste gehört |
Wem die Benutzerliste gehört
TYPO3 im Auslieferungszustand
TYPO3, getrennt je Installation
|
Wem die Benutzerliste gehört
Single Sign-On
deinem Identity Provider
|
| Ein Austritt beendet den CMS-Zugang |
Ein Austritt beendet den CMS-Zugang
TYPO3 im Auslieferungszustand
wenn jemand daran denkt
|
Ein Austritt beendet den CMS-Zugang
Single Sign-On
wenn der Verzeichniseintrag deaktiviert wird
|
| Passwortrichtlinie und zweiter Faktor |
Passwortrichtlinie und zweiter Faktor
TYPO3 im Auslieferungszustand
die von TYPO3, für sich
|
Passwortrichtlinie und zweiter Faktor
Single Sign-On
was dein Provider durchsetzt
|
| Backend und Frontend |
Backend und Frontend
TYPO3 im Auslieferungszustand
ein Benutzerkonzept
|
Backend und Frontend
Single Sign-On
zwei Service Provider, unabhängig nutzbar
|
| Benutzer bei der ersten Anmeldung anlegen |
Benutzer bei der ersten Anmeldung anlegen
TYPO3 im Auslieferungszustand
—
|
Benutzer bei der ersten Anmeldung anlegen
Single Sign-On
optional, standardmäßig aus, je Identität ablehnbar
|
| Abgewiesene Anmeldungen |
Abgewiesene Anmeldungen
TYPO3 im Auslieferungszustand
—
|
Abgewiesene Anmeldungen
Single Sign-On
im sys_log protokolliert
|
| Weg zurück ohne den Provider |
Weg zurück ohne den Provider
TYPO3 im Auslieferungszustand
—
|
Weg zurück ohne den Provider
Single Sign-On
Install Tool, mit eigenen Zugangsdaten
|
Was das nicht ersetzt. Dein Provider entscheidet weiterhin, wer existiert und was er vorlegen muss: einen zweiten Faktor, einen Hardware-Token, eine Conditional-Access-Regel. Single Sign-On sorgt dafür, dass TYPO3 diese Entscheidung übernimmt, statt eine eigene zu treffen.
Für wen Single Sign-On gedacht ist
Organisationen mit Verzeichnisdienst und Audit. Hochschulen, öffentliche Verwaltung, Kliniken, Konzerne mit gemeinsamer IT. Wenn jemand einmal im Jahr beantworten muss, wer worauf Zugriff hatte, ist eine Anwendung mit eigener Benutzerliste die Antwort, die am längsten dauert.
Redaktionen in größeren Unternehmen. Die Leute, die die Website pflegen, sind zuerst Mitarbeiter und dann Redakteure. Ihr Zugang sollte so enden wie jeder andere Zugang auch.
Agenturen, die Kundeninstallationen betreiben. Du trägst Anmeldungen zu Systemen mit dir herum, die schon lange nicht mehr in deiner Verantwortung liegen — und jede davon ist dein Risiko, bis sie jemand entfernt. Mit SSO gibt es nichts mehr zu tragen: Der Zugang hängt am Verzeichnis deines Kunden und endet, wenn das Projekt endet. Die Lizenz gehört zur Installation und wandert bei der Übergabe mit.
Alle, die sich ohnehin schon auf Entra ID oder Keycloak festgelegt haben. Die Arbeit, einen Provider auszuwählen, ist getan. Das hier ist das Stück, das ihn mit dem CMS verbindet.
Systemvoraussetzungen
- TYPO3 v13.4 LTS oder v14.3
- PHP 8.3 oder neuer, mit der Extension
simplexml— die Metadaten des Identity Providers werden als XML gelesen - Ein Identity Provider, der SAML 2.0 spricht, und seine Metadaten als URL oder XML-Datei
- Ein Zertifikatspaar zum Signieren und die Möglichkeit, Umgebungsvariablen zu setzen
SAML selbst übernimmt onelogin/php-saml, als Abhängigkeit mitinstalliert. Beispielkonfigurationen für die lokale Entwicklung mit Keycloak und DDEV liegen der Extension bei.
Installation
Nach dem Kauf hast du in deinem Konto beim b13 Marketplace ein eigenes Composer-Repository.
1
2
composer config repositories.b13 composer https://b13.com/_api/composer/p/<dein-projekt-key>/
composer require b13/sso-authentication
Die Zugangsdaten kommen in die auth.json. Hat dein Setup keinen Composer-Zugriff, findest du in deinem Konto einen ZIP-Download.
Danach: Zertifikate erzeugen, Umgebungsvariablen setzen, TYPO3 beim Identity Provider anmelden und den Bereich einschalten, den du umstellen willst. Die Dokumentation (auf Englisch) führt Schritt für Schritt hindurch und endet mit einer Checkliste für die Produktion und einem Funktionstest. Geh beide durch, bevor du es für erledigt erklärst.
Preis
Ein Preis, pro Jahr und pro Produktivinstanz — eine TYPO3-Installation, eine Codebasis, eine Datenbank. Wie viele Sites, Redakteure oder Identity Provider darin laufen, ändert am Preis nichts. Staging, Test und lokale Installationen desselben Projekts sind abgedeckt.
Du willst deinen ganzen TYPO3-Bestand vereinheitlichen? Das ist der übliche Grund, dieses Produkt zu kaufen — ein Verzeichnis entscheidet überall über den Zugang, nicht auf einer Site von acht. Sag uns, wie viele Produktivinstanzen du betreibst, dann machen wir daraus eine Vereinbarung statt acht einzelner.
Keine Setup-Gebühr. Onboarding gibt es, und es ist freiwillig. Wenn wir die erste Konfiguration mit dir durchgehen sollen, sag Bescheid, dann rechnen wir das getrennt ab.
Warum eine Jahreslizenz. Das hier sitzt in deinem Anmeldeweg und hängt daran, wie TYPO3 Benutzer, Sitzungen und Sites auflöst — der Bereich, der sich zwischen Hauptversionen am stärksten bewegt, und der, in dem ein Sicherheitsrelease nicht warten kann. Genau das deckt die Jahreslizenz ab.
Support
In jeder Lizenz enthalten sind Support per E-Mail, Fehlerbehebungen, Updates für neue TYPO3-Versionen und Sicherheitsfixes. Ein Postfach, eine Warteschlange. Anfragen, die deinen Betrieb aufhalten, ziehen wir vor. Du bekommst eine Vorgangsnummer und kannst jederzeit nach dem Stand fragen.
Priority — 300 € pro Jahr und Lizenz. Eine zugesicherte Antwort innerhalb eines Werktags und Fehlerbehebungen mit Vorrang.
Enterprise — ab 990 € pro Jahr. Reaktionszeiten nach Schweregrad, ein festes Servicefenster, ein Eskalationsweg und ein jährliches Abstimmungsgespräch. Individuell im Vertrag geregelt.
Was der Support nicht abdeckt: Installation und Konfiguration in deinem Projekt, Anpassungen an deinen speziellen Fall, Fehlersuche in deinem eigenen Code oder deiner Umgebung, Datenbereinigung und Schulungen. Pro Anfrage suchen wir bis zu eine Stunde nach der Ursache. Liegt sie außerhalb von Single Sign-On, sagen wir dir, was wir gefunden haben und wo du weitersuchen kannst.
Single Sign-On läuft in deiner Instanz. Eine Verfügbarkeit können wir dir deshalb nicht zusagen. Zusagen können wir, wann wir antworten.
Sicherheitslücken meldest du an [email protected]. Wir lesen jede Meldung, antworten mit einer Einschätzung und stimmen mit dir einen Termin ab, bevor etwas veröffentlicht wird. Braucht dein eigener Prozess ein festes Datum, schreib das in die Meldung, dann vereinbaren wir eins.
FAQ
Was passiert, wenn unser Identity Provider nicht erreichbar ist?
Das Install Tool bleibt mit eigenen Zugangsdaten erreichbar. Ein Administrator kommt also herein und schaltet SSO für den Bereich ab, der hängt. Frontend und Backend werden getrennt konfiguriert, eine Störung auf der einen Seite reißt die andere nicht mit.
Bekommen wir damit eine Zwei-Faktor-Anmeldung?
Die deines Identity Providers, ja. Was er durchsetzt, gilt ab der Umstellung auch für TYPO3-Anmeldungen, weil die Anmeldung dort stattfindet. Single Sign-On bringt keinen eigenen zweiten Faktor mit, und es wäre auch der falsche Ort dafür.
Unser Provider spricht OpenID Connect, nicht SAML. Geht das?
Heute nicht — das hier ist ein SAML-2.0-Service-Provider. Entra ID, Keycloak und ADFS sprechen SAML neben OIDC, in der Praxis ist es also meist eine Frage, eine zweite Anwendung zu registrieren, und keine Frage des Providerwechsels. Sag uns, was bei dir läuft, dann sehen wir es uns gemeinsam an.
Bekommen alle Benutzer aus unserem Verzeichnis ein TYPO3-Konto?
Nur, wenn du es so willst. Benutzer bei der ersten Anmeldung anzulegen ist standardmäßig aus, und eine Identität ohne passenden TYPO3-Benutzer wird abgewiesen und protokolliert. Wo dein Provider die ganze Organisation bedient, entscheidet ein Listener auf BeforeUserCreationEvent in deinem eigenen Code, wer ein Konto bekommt.
Können sich Redakteure weiterhin mit Passwort anmelden?
Das entscheidest du, getrennt für Backend und Frontend. Der SSO-Eintrag steht neben der gewohnten Anmeldung, und die Anmeldung mit Passwort bleibt die erste Wahl, solange du SSO nicht erzwingst — was du kannst, fürs Backend und im Frontend pro Site.
Was ist mit unseren bestehenden Benutzern?
Die werden zugeordnet, nicht ersetzt. Ein Konto, das es schon gibt, wird bei der ersten SSO-Anmeldung wiedergefunden statt doppelt angelegt, und die Spalten, die die Extension führt, stehen neben denen, die TYPO3 schon hatte.
Können wir für Backend und Frontend verschiedene Provider nutzen?
Ja. Es sind getrennte Service Provider mit getrennter Konfiguration: verschiedene Provider, nur einer von beiden Bereichen, oder derselbe Provider zweimal.
Was passiert, wenn die Lizenz ausläuft?
An deiner laufenden Installation ändert sich nichts. Der Code auf deinem Server funktioniert weiter, und nichts schaltet sich ab. Was endet, ist der Zugang zu neuen Releases: Unser Composer-Repository liefert dir keine Downloads mehr.
Für deine Deployment-Pipeline heißt das: Fährt sie bei jedem Build ein composer install gegen unser Repository, schlägt dieser Build nach Ablauf der Lizenz fehl. Deine Website läuft weiter, dein nächstes Deployment nicht. Der Code steht unter GPL-2.0-or-later, die Kopien, die du schon hast, gehören also dir.
Deshalb gibt es eine Nachfrist: Schlägt eine Zahlung fehl, kannst du 13 Tage lang weiter Releases beziehen, während das geklärt wird. Außerdem erinnern wir dich zweimal, bevor die Lizenz ausläuft.
Ist das Open Source?
Der Code steht unter GPL-2.0-or-later, wie jede TYPO3-Extension. Du bezahlst für den Zugang zu den Releases, für Updates für neue TYPO3-Versionen, Sicherheitsfixes und Support. Lesen kannst du jede Zeile.
Brauchen wir eine Lizenz für Staging- und Testsysteme?
Nein, die sind in deiner Produktivlizenz enthalten. Staging, Test, Integration und jede lokale Installation desselben Projekts sind abgedeckt. Gezählt werden nur Produktivinstanzen.
Was zählt als eine Instanz?
Eine TYPO3-Installation mit einer Codebasis und einer Datenbank. Alles darin ist abgedeckt: beliebig viele Sites, Redakteure und Identity Provider. Zehn Kundensites in einer Multisite-Installation sind eine Instanz. Zehn getrennte Installationen sind zehn — sprich uns an.
Deine Organisation weiß längst, wer sich anmelden darf. Single Sign-On ist das, was es TYPO3 sagt.