Single Sign-On (SSO)

Mit einem einfachen, aber wirksamen System möchten wir unseren Nutzern ersparen, bei zig verschiedenen Diensten sich immer wieder neu mit Nutzerkennung und Passwort ausweisen zu müssen. Dieser im Sommer 2010 geschriebene und zuletzt im April 2014 aktualisierte Artikel beschreibt Hintergründe und technische Realisierung. Später wurden noch einige Nachträge ergänzt.

Im Rahmen des MIRO-Projekts (Münster Information System for Research and Organization) wurde auch mit der Realisierung eines Single-Sign-On- (SSO-) Systems für WWW-basierende Dienste begonnen. Mehrere Systeme kamen in die engere Auswahl, letztlich fiel vor einigen Jahren die Entscheidung auf die freie und viel versprechende Open-Source-Software Shibboleth. Ein experimenteller Server (Identity Provider) wurde damals aufgesetzt und mit dem zentralen Active Directory verbunden.

Im Laufe der Zeit wurden verschiedene Dienste (Service Provider) mit der Fähigkeit versehen, sich zur Identitätskontrolle solcher Shibboleth-Server zu bedienen, darunter das heutige ZIVwiki (welches ebenfalls aus dem MIRO-Projekt hervorging) und unser Webmailer perMail. Dabei traten zunehmend grundlegende Probleme zutage. Unter Anderem gingen immer wieder mal Eingaben von Nutzern in WWW-Formulare verloren, beispielsweise mit perMail geschriebene E-Mail-Texte oder Änderungen an ZIVwiki-Texten.

Letztlich stellten sich Shibboleth und andere SSO-Systeme, die bei der regelmäßigen Reauthentifizierung Redirect-Ketten einsetzen (z. B. CAS), für alle Anwendungen, in denen die Nutzer längere Sitzungen durchführen und wiederholt WWW-Formularseiten ausfüllen, als ungeeignet heraus1.

Seine Stärken hat Shibboleth, wenn es um gegenseitige Authentisierung von Personen unterschiedlicher Nutzerverwaltungen mit gleichzeitiger Übermittlung von Angaben zur Person geht, daher bildet Shibboleth zurecht das Rückgrat der Authentifikations- und Autorisierungs-Infrastruktur im deutschen Forschungsnetz (DFN-AAI), die Schwächen bei der Sitzungsverwaltung sprechen aber gegen einen Einsatz in Universitätsportalen, e-Learning-Systemen usw.

Inzwischen wurde innerhalb der Universität zunehmend eine schnelle Entscheidung für ein universitäres Single Sign-On gefordert. So sollen das im Aufbau befindliche Studienassistenzportal und weitere Portale (auch hier wird auf Ergebnisse des MIRO-Projekts aufgebaut) verschiedene bereits existierende Dienste integrieren, ohne dass die Nutzer ständig neu nach ihrem Passwort gefragt werden.

Eine erneute Betrachtung der verfügbaren Systeme mit den mit Shibboleth gemachten Erfahrungen zeigte, dass sich das Konzept eines Portalproxys nicht nur am schnellsten realisieren ließ, sondern auch zum größten Teil längst realisiert war! Einerseits besitzt die Universität Münster seit Jahren gegenüber anderen Hochschulen den riesigen Vorteil einer zentralen Nutzerverwaltung, andererseits besteht der Webserverpark ja aus vorgeschalteten Proxy-Servern und nachgeschalteten Dienste-Servern sowie der Möglichkeit, beliebige weitere WWW-Server weltweit als nachgeschaltete externe Dienste zu integrieren.2 Die Proxy-Server mussten nur noch lernen, die Identitäten der Nutzer mit Hilfe der zentralen Nutzerverwaltung festzustellen und an die nachgeschalteten Dienste durchzureichen, und diese mussten nur noch lernen, den Proxy-Servern zu vertrauen.

Es kostete dann auch nur wenige Stunden, um die notwendigen Ergänzungen zu entwickeln und die ersten Angebote einzubinden. Inzwischen sind zahlreiche Dienste bereit integriert und dient dieses Single Sign-On als essenzielle Grundlage für das Studienassistenzportal, für die zentrale E-Learning-Plattform, für den Webmailer perMail und eine Vielzahl weiterer Dienste.

Wie funktioniert unser Single Sign-On?

Die kurze Realisierungszeit zeigt schon, dass es sich um eine Realisierung nach dem KISS-Prinzip handelt: Keep It Small and Simple3. Das Prinzip besteht darin, dem WWW-Browser vorzugaukeln, alle im Single Sign-On zusammengefassten Dienste bilden einen einzigen Webspace auf einem einzigen Server, der durch eine einfache Basic-Authentisierung geschützt wird.

Die Basic-Authentisierung sieht für den Nutzer so aus, dass beim Abruf einer geschützten Seite ein Dialogfenster geöffnet wird, in dem nach Nutzerkennung und Passwort gefragt wird. Der WWW-Browser merkt sich die Eingaben und sendet sie dann bei jedem Abruf einer Seite aus diesem einen Webspace mit. Während der Datenübertragung wird das Passwort dadurch geschützt, dass beim Zugriff auf die im Single Sign-On zusammengefassten Dienste grundsätzlich alle Daten verschlüsselt übertragen werden (HTTPS-Verbindungen) und dass der Portalproxy bereits beim Verbindungsaufbau seine Identität gegenüber dem Browser durch ein X.509-Zertifikat nachgewiesen hat.

Der wesentliche Nachteil der Basic-Authentisierung besteht darin, dass man sich nicht abmelden kann, denn der Browser merkt sich die Angaben solange, bis er entweder geschlossen wird oder bis vom Nutzer die Browserfunktion Private Daten löschen bzw. Neueste Chronik löschen aufgerufen wird. Manche Browser (Firefox, Safari, nicht jedoch Internet Explorer) vergessen die Angaben auch dann, wenn der Nutzer versucht einen Bereich zu betreten, den er nicht betreten darf. Der Vorteil besteht aber darin, dass alleine der Browser und keine sonstige Instanz irgendwo im Netz irgendwelche Authentisierungsinformationen aufbewahrt. Bestimmte bei anderen SSO-Systemen denkbare Angriffe wie Session Hijacking laufen also von vornherein ins Leere.

Dass man Nutzerkennung und Passwort nur in vertrauenswürdige Browser eintippen sollte, gilt natürlich unabhängig vom verwendeten SSO-System und spricht daher nicht gegen die Verwendung der Basic-Authentisierung.

Der scheinbar einzige Webspace ist unter der WWW-Adresse https://sso.uni-muenster.de/ zu erreichen. Die einzelnen Dienste liegen in Unterverzeichnissen dieses Webspaces: Unter https://sso.uni-muenster.de/perMail/ finden Sie unseren Webmailer perMail, unter https://sso.uni-muenster.de/IT-Portal/ unser IT-Portal, unter https://sso.uni-muenster.de/LSF/ das zentrale Lehrveranstaltungsportal HIS-LSF und unter https://sso.uni-muenster.de/ZIVwiki/ das zentrale Wiki-System der Universität. Letztlich ist sogar jeder Webspace XYZ, der unter http://www.uni-muenster.de/XYZ/ oder https://www.uni-muenster.de/XYZ/ zu erreichen ist, auch unter https://sso.uni-muenster.de/XYZ/ zu erreichen. Es kostet einen Infoanbieter im Webserverpark also nur wenige Minuten, um die bereits automatisch erledigte Einbindung ihrer geschützten Inhalte für das Single Sign-On zu perfektionieren.

Unsere Proxy-Server kontrollieren jetzt bei jedem Zugriff auf sso.uni-muenster.de anhand von Nutzerkennung und Passwort die Identität des Nutzers (Authentisierung) und entscheiden dann (wie bisher schon bei www.uni-muenster.de) anhand des URL-Pfades, an welchen Dienste-Server die Anfrage weitergeleitet wird. Neu ist, dass in der weitergeleiteten Anfrage der Proxy-Server sich gegenüber dem Dienste-Server mit einer speziellen Nutzerkennung und zugehörigem Passwort ausweist und zusätzlich die Nutzerkennung des anfragenden Nutzers in der Kopfzeile X-Trusted-Remote-User mitliefert. Es wird vom Proxy-Server sichergestellt, dass diese Kopfzeile nur in dann in weitergeleiteten Anfragen vorkommt, wenn tatsächlich eine erfolgreiche SSO-Authentisierung stattgefunden hat. (Das gilt auch für die weiteren unten genannten Kopfzeilen.)

Die Dienste-Server nehmen diese Anfrage entgegen, überprüfen anhand der IP-Adresse und/oder anhand der speziellen Nutzerkennung die Identität des Proxy-Servers und verwenden danach für die Kontrolle, ob der anfragende Nutzer den jeweiligen Dienst überhaupt nutzen darf (Autorisierung), die Nutzerkennung aus der Kopfzeile X-Trusted-Remote-User. Falls der Dienste-Server Teil des Webserverparks ist, wird dies bereits von den von uns modifizierten Apache-Servern erledigt, welche nach der Authentisierung (Identitätskontrolle), aber vor der Autorisierung (Zugangskontrolle, z. B. mit Require dbm-group ...) die in X-Trusted-Remote-User übergebene Nutzerkennung nach REMOTE_USER umkopieren. Der Betreiber eines Webspaces im Webserverpark braucht sich also gar nicht mehr darum zu kümmern, ob der Nutzer sich über das Single Sign-On oder über den herkömmlichen Weg angemeldet hat, er erhält in beiden Fällen die Nutzerkennung des authentifizierten und autorisierten Nutzers in der Umgebungsvariablen REMOTE_USER und nimmt in aller Regel nicht einmal wahr, dass das Single Sign-On benutzt wurde.

Dienste-Server außerhalb des Webserverparks müssten entweder ebenfalls den Apache-Server oder aber die Anwendung selbst geringfügig modifizieren (vier Zeilen im Quelltext ergänzen), dabei sind wir gerne behilflich. Es besteht auch die Möglichkeit (so ist HIS-LSF eingebunden), mit einem kleinen Zwischenskript im Webserverpark die Single-Sign-On-Authentisierung in eine für den Dienst passende Authentisierung umzuwandeln.

Welche Anpassungen sollte ein Infoanbieter durchführen?

Grundsätzlich sollte ein Infoanbieter bei Querverweisen innerhalb des Webserverpark auf die explizite Angabe des Rechnernamens verzichten, also schreiben:

  • einfach <a href="/IT-Portal/?lang=de">
    statt <a href="http://www.uni-muenster.de/IT-Portal/?lang=de">
    oder <a href="https://sso.uni-muenster.de/IT-Portal/?lang=de">

  • einfacher <img src="/imperia/md/images/allgemein/farbunabhaengig/lang_flag_en.gif" />
    statt <img src="http://www.uni-muenster.de/imperia/md/images/allgemein/farbunabhaengig/lang_flag_en.gif" />

  • einfach <a href="/LSF/">
    statt <a href="https://studium.uni-muenster.de/qisserver/rds?state=user&type=0">

Seine zugangsgeschützten Bereiche sollte ein Infoanbieter mit folgenden drei Dateien konfigurieren, deren Inhalt natürlich angepasst werden kann:

  • .htaccess und .htsslaccess:

    RedirectPermanent / https://sso.uni-muenster.de/ 

  • .htssoaccess:

    AuthType Basic
AuthName "Nur fuer Uni-Angehoerige"
AuthBasicProvider dbm
AuthDBMUserFile /www/data/usersso
AuthDBMGroupFile /www/data/groups
Require dbm-group an=uni=unsicher

Wenn alle drei Dateien angelegt sind, greift beim Zugang über http://www.uni-muenster.de die Datei .htaccess, beim Zugang über https://www.uni-muenster.de die Datei .htsslaccess und beim Zugang über https://sso.uni-muenster.de die Datei .htssoaccess.

Es ist auch möglich, sowohl Personen aus der zentralen Nutzerverwaltung als auch weitere Personen zuzulassen. Dann sollte man durch vorgeschaltete Seiten die Personen aus der zentralen Nutzerverwaltung auf https://sso.uni-muenster.de/XYZ/ leiten und andere Personen auf https://www.uni-muenster.de/XYZ/. In die Datei .htsslaccess schreiben Sie dann die folgenden Zeilen, die beiden anderen Dateien bleiben unverändert:

AuthType Basic
AuthName "Nur fuer unsere auswaertigen Gaeste"
AuthBasicProvider file
AuthUserFile /pfad/zur/Passwortdatei/mit/den/Gaesten
Require valid-user

Verwenden Sie aber niemals Require valid-user zusammen mit AuthDBMUserFile /www/data/users oder AuthDBMUserFile /www/data/usersso, denn dann gewähren Sie auch abgelaufenen, gesperrten und verschiedenen sonstigen unerwünschten Nutzern den Zugriff!

Für Ihre Fragen steht der Autor gerne zur Verfügung.

Weiterer Ausbau

Nachdem das oben beschriebene SSO-System realisiert war, drängten sich einige leicht realisierbare Erweiterungen geradezu auf. So sind folgende Erweiterungen bereits realisiert:

Authentisierung mit X.509-Zertifikat

Alternativ zur Authentisierung mittels Nutzerkennung und Passwort kann auch eine Authentisierung anhand eines X.509-Client-Zertifikats vorgenommen werden, wie es von allen S/MIME-Nutzern verwendet wird. Dazu wurde die WWW-Adresse https://xsso.uni-muenster.de hinzugefügt.

Unsere Proxy-Server akzeptieren derzeit X.509-Zertifikate aus der Global-Hierarchie der DFN-PKI, welche eine E-Mail-Adresse der Form nutzerkennung@uni-muenster.de oder nutzerkennung@wwu.de enthalten. Solche Zertifikate werden von der Zertifizierungsstelle der Universität Münster (WWUCA) ausgestellt. (Zum Auslesen der Nutzerkennung aus solchen Zertifikaten wurde eine weitere kleine Apache-Erweiterung entwickelt und in die Proxy-Server integriert.)

Falls auf dem eigenen Rechner entsprechende Treiber installiert sind, kann das Zertifikat gerne auf einer Smartcard oder einem eToken liegen, Anleitungen dazu finden Sie auf den Seiten der WWUCA. Dann haben Sie wirklich einen höchst sicheren SSO-Zugang realisiert. Insbesondere ist dann auch das Logout-Problem gelöst: Sobald Sie die Smartcard bzw. das eToken entfernen, sind Ihre SSO-Sitzungen automatisch unterbrochen und können nur fortgesetzt werden, wenn Sie die Smartcard bzw. das eToken wieder einstecken.

Auch Zertifikate aus den internen Zertifizierungshierarchien unserer Windows-Domains WWU und UNI-MUENSTER können verwendet werden.

Die Proxy-Server informieren die Dienste-Server in der Kopfzeile X-Trusted-Remote-Auth, welches Authentifizierungsverfahren zum Einsatz gekommen ist und ggf. welche Zertifizierungsstelle die Identität bestätigt hat. Dadurch ist es möglich, dass bestimmte Dienste erhöhte Anforderungen an die Authentifizierung stellen. Beispielsweise verlangt unser IT-Portal für administrative Tätigkeiten (z. B. um einem Nutzer ein neues Passwort zu setzen) zwingend ein Zertifikat der WWUCA.

Wenn Bedarf besteht, kann dieses Verfahren gerne erweitert werden, um beispielsweise universitätsfremden Zertifikatbesitzern den Zugang zu gewissen Angeboten zu gewähren. Wenden Sie sich bei Interesse an den Autor.

Authentisierung mit Shibboleth

Wir haben es geschafft, unsere Proxy-Server zu „shibbolethisieren“. Dazu wurde die WWW-Adresse https://ssso.uni-muenster.de hinzugefügt. Anfänglich nutzten die Proxy-Server nur den experimentellen Shibboleth-Server aus dem MIRO-Projekt, seit August 2012 sind sie als Service Provider in die Authentifikations- und Autorisierungs-Infrastruktur des Deutschen Forschungsnetzes (DFN-AAI) eingebunden und seit April 2014 auch in den pan-europäischen Verbund eduGAIN. Damit ist es möglich, WWW-Seiten so zu schützen, dass bestimmte Personen anderer Hochschulen darauf zugreifen können und sich dabei mit ihrer heimischen Nutzerkennung und ihrem heimischen Passwort ausweisen können. Voraussetzung ist allerdings, dass der vom Nutzer verwendete Identity Provider die Identität nicht nur kontrolliert, sondern auch als eduPersonPrincipalName oder als persistent ID (eine Art Pseudonym) übermittelt.

Allerdings nehmen Sie bei Nutzung dieses Zugangs natürlich die ganzen oben beschriebenen Nachteile wieder in Kauf. Zwar besitzt Shibboleth ab Version 2.2 einen Mechanismus zum Zwischenspeichern von POST-Daten, den wir auch aktiviert haben, dieser funktioniert jedoch nur bei Formularen des Typs application/x-www-form-urlencoded und nur bis zu einer beschränkten Größe, nicht jedoch für das bei uns intensiv eingesetzte multipart/form-data.

Digest- statt Basic-Authentisierung

Bei Untersuchungen unserer Wirtschaftsinformatiker wurden WWW-Browser entdeckt, die ein Passwort, welches zur Basic-Authentisierung über eine HTTPS-Verbindung eingetippt wurde, danach automatisch auch bei einer unverschlüsselten HTTP-Verbindung zum gleichen Server mitsenden. Um das Abfischen der Passwörter auf diesem Weg zu verhindern, nehmen unsere SSO-Server keine HTTP-Zugriffe mehr an. Sobald fast alle Nutzer einmal ihr Passwort geändert und dadurch in der entsprechenden Datei abgelegt haben, werden wir die Basic-Authentisierung durch die Digest-Authentisierung ersetzen und können wir dann die Umleitungen von HTTP zu HTTPS wieder aktivieren.4

Formular- statt Digest-Authentisierung

Nachtrag Mai 2019: Um endlich eine für alle Browser funktionierende Abmeldung zu ermöglichen, wird im Mai 2019 die Digest-Authentisierung durch eine Formular-Anmeldung, basierend auf dem Apache-Modul mod_auth_form, ersetzt.

Personenbezogene Daten

Unsere Proxy-Server können ähnlich wie bei Shibboleth Informationen über den angemeldeten Nutzer an den Dienste-Server übermitteln. Neben den oben beschriebenen Kopfzeilen X-Trusted-Remote-User und X-Trusted-Remote-Auth werden dazu auch X-Trusted-Remote-Iden, X-Trusted-Remote-Name, X-Trusted-Remote-Attr und X-Trusted-Remote-Role gesetzt.

In X-Trusted-Remote-Iden wird die ursprüngliche Identitätsangabe des Nutzers übermittelt, aus der die in X-Trusted-Remote-User übermittelte Nutzerkennung hergeleitet wurde.

In X-Trusted-Remote-Name wird der volle Name des Nutzers übermittelt.

Welche Daten in X-Trusted-Remote-Attr übermittelt werden, wird individuell mit dem einzelnen Diensteanbieter abgeklärt. Beispielsweise werden Studienassistenzportal und E-Learning-System auf diese Weise über Name, Matrikelnummern und Studiengänge des angemeldeten Nutzers informiert, ohne dass dem Diensteanbieter gleich eine Datenbank aller Daten aller Nutzer zur Verfügung gestellt werden muss.

In X-Trusted-Remote-Role werden Rollenangaben (beispielsweise bei Verwendung der DFN-AAI die Scoped Affiliations) übermittelt, die von den Dienste-Servern für Authorisierungszwecke ausgewertet werden können.

(Zum effizienten Auslesen der zusätzlichen Angaben aus dem zentralen Identitätsmanagement, welches ebenfalls Ergebnis eines MIRO-Projekts ist, und den weiteren je nach SSO-Methode unterschiedlichen Quellen wurde eine weitere kleine Apache-Erweiterung entwickelt und in die Proxy-Server integriert. Eine weitere, in die Dienste-Server im Webserverpark integrierte Apache-Erweiterung blendet diese Angaben scheinbar in unsere zentrale Nutzergruppendatei ein, was Angaben wie require dbm-group @member@uni-koeln.de ermöglicht.)

Single Sign Off

Zwar gibt es für die meisten Authentisierungsverfahren aus technischen Gründen keine Möglichkeit der Abmeldung, trotzdem wurde eine Art Single Sign Off realisiert. Es wird allen Infoanbietern empfohlen, in ihren Anwendungen einen Link (oder Button) anzubieten:

Abmelden

Abhängig von der verwendeten Authentisierungsmethode und vom verwendeten Browser wird dann entweder die Single-Sign-On-Sitzung direkt beendet oder erklärt, wie die Sitzung beendet werden kann.

Fazit

Die wohl überlegte Konzeption des Webserverparks ermöglichte eine einfache und schnelle Realisierung eines trotz des KISS-Prinzips hochwertigen, zuverlässigen und erweiterbaren Single-Sign-On-Systems.

Beliebige WWW-Angebote aus der Universität können integriert werden, bei Angeboten außerhalb des Webserverparks oder unter eigenen Hostnamen können aber kleine Anpassungen notwendig sein.

Die Praxis wird zeigen, wie weit das jetzt gewählte Konzept trägt, bislang jedenfalls, auch zwei Jahre nach Inbetriebnahme, sind außer den Beschränkungen beim Abmelden keine Grenzen in Sicht.

Bei Fragen wenden Sie sich bitte an wwwadmin@uni-muenster.de.

 

 

 

Fußnoten

1 Selbst die Shibboleth-Entwickler schreiben auf https://spaces.internet2.edu/display/SHIB/CPPSPLoadBalanced: "Avoid the SP's session caching layer and quickly establish a cluster-safe session using some other application-specific technology."

2 Eine ausführliche Übersicht über Konzeption und technische Einzelheiten unseres Webserverparks finden Sie unter http://www.uni-muenster.de/ZIV/Technik/WWW/.

3 Auf http://de.wikipedia.org/wiki/KISS-Prinzip finden Sie zahlreiche Wortspiele gleicher Bedeutung.

4 Bei einer ausführlichen Suche nach Software, die Probleme mit der Digest-Authentisierung hat, haben wir als einzigen WWW-Browser den lynx und als einzige sonstige HTTP-Client-Software den PHP-fopen-Wrapper für https://-URLs gefunden.

Grafik Single Sign OnN