Da häufig unterschiedlich Dinge mit Single Sign-On assoziiert, werden, ist eine Erläuterung der hier vorgestellten Methode notwenig. Das Prinzip beruht darauf, dass sich ein Benutzer nur einmal an seinem Betriebssystem anmeldet und anschließend beim Aufruf der verschiedenen Webanwendungen keine weitere Authentifizierung benötigt. Dabei ist es gleichgültig welches Betriebssystem er verwendet. Die Authentifizierung an der Webanwendung übernimmt ein Benutzerzertifikat, das im Webbrowser hinterlegt ist. Das Benutzerzertifikat kann man mit einem Personalausweis vergleichen, anhand dem der Webserver erkennt, welcher Benutzer sich gerade bei ihm anmelden möchte. Gelingt die Authentifizierung, reicht der Webserver die Benutzerinformationen an TYPO3 weiter. Dabei ist zu beachten, dass der Benutzer an dieser Stelle nur authentifiziert, nicht aber autorisiert wird. Die Zugangsberechtigungen steuert TYPO3 mit Hilfe der Benutzerverwaltung.

Zertifikate beruhen auf Vertrauensverhältnissen. Benutzer- und Serverzertifikaten kann man vertrauen, wenn Sie von vertrauenswürdigen Zertifizierungsstellen unterschrieben oder herausgegeben wurden. In jedem Webbrowser sind bereits einige Stammzertifikate von Zertifizierungsstellen wie GeoTrust, Thawte oder Verisign hinterlegt. Daher vertrauen Webbrowser Zertifikaten, die von diesen Zertifizierungsstellen unterschrieben wurden. Jedes Zertifikat besitzt einen öffentlichen und einen privaten Schlüssel. Der öffentliche Schlüssel kann weitergegeben werden, der private Schlüssel darf niemals weitergegeben werden.

Von VeriSign [1] und anderen Anbietern unterzeichnete Zertifikate sind relativ teuer. Bei dem hier beschriebenen Szenario ist es daher sinnvoll, eine eigene Zertifizierungsstelle einzurichten. Dieser Artikel beschreibt dies exemplarisch mit OpenSSL [2] unter Linux. Dazu sind einige Vorbereitungen notwendig. Zunächst müssen die Ordner „certs“, „crl“, „newcerts“, „private“ und „p12“ angelegt werden. Außerdem wird eine leere Datei mit dem Namen „index.txt“ und eine weitere Datei namens „serial“ mit dem Inhalt „01“ benötigt. Die Datei „openssl.cnf“ kann aus dem OpenSSL-Verzeichnis in das aktuelle Verzeichnis kopiert werden. In dieser Datei werden alle wichtigen Einstellungen vorgenommen. etwa die Gültigkeitsdauer des Zertifikats. Nachdem die beschriebenen Vorbereitungen abgeschlossen sind, wird der Schlüssel für die Zertifizierungsstelle mit folgender Zeile erstellt:

#> openssl genrsa -aes256 -out private/rootca.key 2048

Mit diesem Schlüssel wird anschließend das Zertifikat für die Zertifizierungsstelle mit einer Gültigkeitsdauer von 20 Jahren erstellt. Dabei ist zu beachten, dass das Zertifikat ausreichend lange gültig sein sollte, da das Austauschen des Zertifikates der Stammzertifizierungsstelle sehr aufwendig ist.

#> openssl req -config openssl.cnf -new -days \ 
#> 7300 -x509 -key private/rootca.key -out cert/rootca.crt

Nachdem das Zertifikat für die Zertifizierungsstelle erstellt wurde, kann das erste Benutzerzertifikat ausgestellt werden:

#> openssl genrsa -aes256 -out private/support@ml-networld.de.key 2048
#> openssl req -config openssl.cnf -new -key private/support@ml-networld.de.key \ 
-out certs/support@ml-networld.de.csr
#> openssl ca -config openssl.cnf -in certs/support@ml-networld.de.csr \
-cert certs/rootca.crt -keyfile private/rootca.key -out certs/support@ml-networld.de.crt

Abschließend wird das Zertifikat ins PKCS12-Format umgewandelt, damit es sich bequem in den Webbrowser importieren lässt:

#> openssl pkcs12 -export -inkey private/support@ml-networld.de.key -in \
certs/support@ml-networld.de.crt -certfile certs/rootca.crt -out \ 
p12/support@ml-networld.de.crt.p12

Zusätzlich muss das Zertifikat der Zertifizierungsstelle als vertrauenswürdig in den Webbrowser importiert werden. Anschließend kann sich der Webbrowser am Webserver authentifizieren. Bei der Erstellung der Benutzerzertifikate ist zu beachten, dass im Feld „Common Name“ die E-Mail-Adresse richtig eingetragen wird, das sie später nicht korrigiert werden kann. Serverzertifikate werden analog zu den Benutzerzertifikaten angelegt, nur dass im dem Feld „Common Name“ die URL des Webservers eingetragen wird. Nachdem die Zertifikate erstellt wurden, muss jetzt der Webserver konfiguriert werden. Das hier gezeigte Beispiel beruht auf Apache2. An dieser Stelle wird davon ausgegangen, dass der Webserver bereits für SSL konfiguriert wurde. Mit folgender Zeile wird bestimmt, von welcher Zertifizierungsstelle die Benutzerzertifikate akzeptiert werden:

SSLCACertificateFile /etc/apache2/ssl/rootca.crt

Nur Zertifikate dieser Zertifizierungsstelle werden akzeptiert. Falls Zertifikate von mehreren Zertifizierungsstellen zum Einsatz kommen sollen, kann im Konfigurationsparameter „SSLCACertificatePath“ das Verzeichnis angegeben werden, in dem sie sich befinden. Anschließend wird festgelegt, für welches Verzeichnis auf dem Server die Authentifizierung gültig sein soll.

<Directory /var/www/sso/htdocs>
	SSLOptions +FakeBasicAuth
	AllowOverride none
	AuthUserFile /etc/apache2/ssl/ssl_user.txt
	AuthType Basic
	AuthName "SSL Auth"
	Require valid-user
</Directory>

In der Datei „/etc/apache2/ssl/ssl_user.txt“ sind die Benutzer aufgeführt, die berechtigt sind, auf das angegebene Verzeichnis zuzugreifen. Dadurch wird sichergestellt, dass nicht alle Besucher mit einem gültigen Zertifikat die Webseite aufrufen können, sondern nur die gewünschten. In jeder Zeile steht der Zertifikatsstring und, durch einen Doppelpunkt getrennt, das DES-verschlüsselte Passwort.

/C=DE/ST=Hessen/O=ml networld gmbh & co. kg/OU=Webservices/CN=support@ml-networld.de/emailAddress=support@ml-networld.de:xxj31ZMTZzkVA

Sobald die Konfiguration des Webservers abgeschlossen ist und die Authentifizierung mittels Zertifikaten funktioniert, kann die TYPO3-Installation konfiguriert werden. Dabei kommt die Extension „Single Sign On“ (Extensionkey: ml_sso) [3] zum Einsatz. Sie erkennt, ob der Webserver die Authentifizierung bereits durchgeführt hat und simuliert in diesem Fall eine manuelle Anmeldung. Die Extension funktioniert sowohl für Website-Benutzer als auch für TYPO3-Backend-Benutzer. Das exakte Verhalten ist im Extension-Manager konfigurierbar. Nach der Installation sind im Extension-Manager zahlreiche Konfigurationsoptionen verfügbar.

Die Checkboxen „enableSingleSignOnFE“ und „enableSingleSignOnBE“ aktivieren die zertifikatbasierte Authentifizierung von Website- und Backend-Benutzer.
Die in „regExprFE“ und „regExprBE“ definierten regulären Ausdrücke müssen so formuliert sein, dass der zu prüfende Parameter der PHP-Funktion zur Verfügung steht. Zur Veranschaulichung ein Beispiel: Hat der Server den Benutzer authentifiziert, setzt er als Benutzernamen in der Variablen „PHP_AUTH_USER“ beispielsweise folgendes ein:

/C=DE/ST=Hessen/O=ml networld gmbh & co. kg/OU=Webservices/CN=support@ml-networld.de/emailAddress=support@ml-networld.de

Über den regulären Ausdruck „^.*emailAddress=(.*)$“ wird „support@ml-networld.de“ extrahiert. Die entscheidende Eigenschaft muss also in Klammern gesetzt werden, um sie entsprechend zur Verfügung zu stellen. Die Extension verwendet die PHP-Funktion „eregi“, um den regulären Ausdruck anzuwenden und unterscheidet daher nicht zwischen Groß- und Kleinschreibung.

Die Eingabefelder „fieldNameFE“ und „fieldNameBE“ legen fest, in welchen Feldern der Datenbanktabellen die per regulärem Ausdruck gefundene Eigenschaft gesucht werden soll. Für Website-Benutzer (fieldNameFE) können Sie frei aus den Feldern der Tabelle „fe_users“ wählen, für Backend-Benutzer (fieldNameBE) entsprechend aus den Feldern der Tabelle „be_users“.

Bei der Verwendung der Extension „Single Sign On“ sollte darauf geachtet werden, dass die zu prüfenden Eigenschaften eindeutig definiert sind. Sollten mehrere Zeilen von der Datenbank zurückgeliefert werden, führt die Extension keine Anmeldung durch, da nicht bestimmt werden kann, welcher Benutzer den Zugriffsversuch unternommen hat.

Die Kombination aus browserbasierter Authentifizierung und der beschriebenen Extension bringt TYPO3 mit überschaubarem Aufwand dazu, die Besitzer von Zertifikaten automatisch zu autorisieren. Die Eingabe von Benutzernamen und Passwörtern entfällt – eben Single Sign-On.

Die Autoren

Kai Riasol ist leitender Administrator bei der ml networld gmbh und co. kg. Diese bietet Webhosting, insbesondere für TYPO3, und umfassende Systembetreuung an. Kai Riasol besitzt zahlreiche Microsoft-Zertifikate, ist aber doch mit Leib und Seele Linux-Administrator.

Markus Friedrich wohnt in einer fast 100 Jahre alten Mühle, wo er sich fern der Außenwelt dem Quelltext widmet. Er hat bisher zehn TYPO3 Extensions veröffentlicht und ist TYPO3-Chefentwickler bei der media lights gmbh. Kernkompetenz des Unternehmens ist die Entwicklung von hochwertigen Internet-Lösungen – meist auf Basis von TYPO3.