Authentifizierungsservice

Georg Gollmann

Der ZID betreibt seit einigen Jahren einen Authentifizierungsdienst auf Basis der White Pages Passworte. Die Implementierung entspricht aber nicht mehr den heutigen Sicherheitsanforderungen. Deshalb wird dieser Dienst auf eine neue Basis gestellt.

Übersicht

Um das White Pages Passwort guten Gewissens zur Anmeldung bei verschiedenen Anwendungen einsetzen zu können, dürfen die Passworte der Benutzer nicht mehr den einzelnen Servicebetreibern bekannt werden. Eine Klartextübertragung ist selbstverständlich auch zu vermeiden.

Für Web-Anwendungen wird daher ein Authentifizierungsserver bereitgestellt, der den Benutzer nach erfolgreicher Authentifizierung zum jeweiligen Anwendungs-server weiterleitet. Für den Benutzer ist dieser Vorgang transparent, es sieht nur die von der jeweiligen Anwendung erzeugten Webseiten.

Bei Sicherheitsfragen existiert immer ein Konflikt zwischen Bequemlichkeit und Sicherheit. Ein Aspekt in diesem Zusammenhang ist, ob der Adressmanager das White Pages Passwort eines Benutzers setzen darf. Dies erleichtert die Neuvergabe eines vergessenen Passwortes, erlaubt aber auch dem Adressmanager, die Identität des Benutzers anzunehmen. Da die Beurteilung dieses Sachverhaltes von der individuellen Situation des einzelnen Benutzers abhängt, kann er wählen, ob er dem Adressmanager dieses Recht gibt oder nicht. Standardeinstellung ist, es zu vergeben. Dies ist notwendig, damit der Adressmanager neuen Mitarbeitern ein Passwort zuweisen kann.

Implementierung

Die Implementierung muss sich auf die im Feld vorhandenen Klienten stützen. In der heutigen Umgebung ist der Web-Browser der universelle Klient. Leider wird die in RFC 2069 beschriebene "Digest" Authentifizierung gerade von derzeit weit verbreiteten Browsern nicht unterstützt. Es wurde daher ein an Kerberos angelehntes Verfahren gewählt: Das Web-Anmeldeformular schickt die Daten (Benutzeridentifizierung, Passwort und An-wendungsidentifikation) über HTTPS an den Authentifizierungsserver. Nach erfolgreicher Überprüfung des Passwortes wird eine "Temporary Redirect" Antwort erzeugt, die einen Session Key enthält und den Browser des Benutzers an den Anwendungsserver weiterleitet. Der Session Key wird aus der Benutzeridentifikation, einer Zeitmarke, dem Rechnernamen des Benutzers und einem gemeinsamen Geheimnis zwischen Authentifizierungs- und Anwendungsserver gebildet. Da dem Anwendungsserver diese Bestimmungsstücke auch bekannt sind, kann er den Session Key auf Gültigkeit überprüfen.

Ablauf der HTTPS-Transfers

Technische Beschreibung

Siehe auch: http://sts.tuwien.ac.at/go/Authentifizierung.html

Aufruf

Typischerweise wird das Anmeldeformular vom Applikationsserver angeboten, die Form-Action zeigt auf den Authentifizierungsserver. Ein Beispiel findet sich unter https://studman.ben.tuwien.ac.at/studacct/ (Statusabfrage und Passwortänderung für Studentenaccounts).

Der Aufruf der Authentifizierungsservices hat eine der beiden Formen

https://iu.zid.tuwien.ac.at:8008/0.authenticate? app=...&oid=...&pw=... https://iu.zid.tuwien.ac.at:8008/0.authenticate? app=...&mn=...&pw=...

Hinweis: Hostname und Portnummer könnten sich noch ändern.

app: die zugewiesene Anwendungsnummer
oid: ObjectID
mn: Matrikelnummer
pw: White Pages Passwort

Ein optionales Feld param wird an den Anwendungsserver durchgereicht. Dieses Feld darf allerdings keine Zeichen enthalten, die eine spezielle URL-Codierung benötigen (Leerzeichen, etc.).

Für jede Anwendung wird gespeichert:

der URL des Services
das gemeinsame Geheimnis (siehe unten: appServerSecret)
ob die OID oder die Matrikelnummer als userID verwendet werden soll
welches Format der Redirect-URL benutzen soll

Antwort

Der Redirect-URL kann wahlweise eine von zwei Formen haben:

https://userID:sessionKey@host/path
Es ist zu beachten, dass viele Browser die Authentifizierungsinformation erst weiterleiten, wenn sie vom Anwendungsserver mit einer "401 Unauthorized" Antwort dazu aufgefordert werden. Ebenso haben viele Browser die Tendenz, alte Authentifizierungsinformation weiterzuverwenden, auch wenn sie einen neuen Redirect-URL bekommen haben. Einige stellen für den Benutzer transparent auf die neuen Daten um, wenn der Anwendungsserver "401 Unauthorized" antwortet. Manche sind aber hartnäckig und verlangen das Eingreifen des Benutzers.
https://host/path?user=userID&sKey=sessionKey

Um den Session Key zu bilden, werden die Elemente userID, timeStamp, clientHostName und appServerSecret zusammengehängt und der SHA-1 Hash gebildet (als 40 Zeichen Hex-String formatiert).

userID
Entweder die ObjectID oder -bei Studenten -die Matrikelnummer.
timeStamp
Die Zeit in Sekunden seit 1.1.1970 0:0:0 UTC (Unix time), ganzzahlig dividiert durch 10. Die Division vermindert die Anforderungen an die Synchronisation der Server.
clientHostName
Der DNS Name des Rechners des Benutzers in Kleinschreibung.
appServerSecret
Ein gemeinsames Geheimnis zwischen Authentifizierungsserver und dem jeweiligen Anwendungsserver.

Der Anwendungsserver bildet ebenfalls den Hash und vergleicht mit dem übergebenen Sessionkey. Dabei ist zu berücksichtigen, dass die Uhren der Server u.U. nicht perfekt synchronisiert sind und daher beim timeStamp auch Werte vor und nach der aktuellen Zeit probiert werden müssen. Beispiele in PHP und Perl finden sich unter http://sts.tuwien.ac.at/go/AuthBeispiel.html.

Fehlerbehandlung

Kann der Benutzer nicht ermittelt werden, wird ein Redirect der Form
https://host/path?error=user
zurückgegeben.

Ist das Passwort falsch, ist die Redirect-Antwort https://host/path?error=password&user=userID.

Ein allfälliges param Feld in der Anfrage wird ebenfalls mitgeschickt.

Verfügbarkeit

Es wird eine Verfügbarkeit von besser als 99,9% während der üblichen Dienstzeiten, 99% außerhalb, angestrebt.

Seitenanfang | ZIDline 7 - Oktober 2002 | ZID | TU Wien