Anzeige
Anzeige
Software & Entwicklung

TYPO3 und Zertifikate: Single Sign-On

Wer kennt ihn nicht, den großen Wust an Zugangsdaten und das ständige neue Einloggen bei verschiedenen Systemen. Nicht selten geht dabei der Überblick verloren. Abhilfe verspricht das Konzept Single Sign-On.

5 Min.
Artikel merken
Anzeige
Anzeige

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.

Wie funktionieren Zertifikate?

Anzeige
Anzeige

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.

Erstellung einer Zertifizierungsstelle

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:

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

Listing 1

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.

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

Listing 2

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

SHELL
#> 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

Listing 3

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

Anzeige
Anzeige
SHELL
#> 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

Listing 4

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:

CONFIG
SSLCACertificateFile /etc/apache2/ssl/rootca.crt

Listing 5

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.

CONFIG
<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>

Listing 6

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.

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

Listing 7

Zertifikate in TYPO3

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:

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

Listing 8

Ü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.

Anzeige
Anzeige

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.

Fazit

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.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Kommentare

Community-Richtlinien

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Kommentar abgeben

Melde dich an, um Kommentare schreiben und mit anderen Leser:innen und unseren Autor:innen diskutieren zu können.

Anmelden und kommentieren

Du hast noch keinen t3n-Account? Hier registrieren

Anzeige
Anzeige