Single Sign On mit dem CAS-Server

07.11.2011hinzugefügt von Odilo Oehmichen

SSO – Wozu?

Single Sign On bietet dem Benutzer die Annehmlichkeit sich ein einziges Mal zu authentifizieren und dann Zugriff auf mehrere Webauftritten bzw. Applikationen zu haben. Damit verbunden ist, dass sich der Benutzer nur eine Username-Passwort-Kombination merken muss, anstatt eine für jede Applikation. Das spart nicht nur Zeit, sondern auch Hirnzellen.

Aus Betreibersicht bietet sich die Möglichkeit den Zutritt zentral kontrollieren zu können. Das Passwort wird nur an einer Stelle validiert. Im Gegenzug ist eine zentrale Authentifizierungsstelle natürlich auch ein Single Point of Failure: einerseits in Bezug auf Sicherheit und andererseits bezüglich der Last.

JA-SIG CAS

Für die Umsetzung einer Single Sign On gibt es etliche Lösungen am Markt, die verschiedene Bedürfnisse bedienen und unterschiedliche Komplexitäten mit sich bringen. – Hier gibt es mächtige Lösungen von Kerberos bis zu OpenID oder OAuth.
Im Java-Umfeld ist schon länger das JA-SIG CAS Projekt (Central Authentication Service) eine kleine Perle, die vorallem im universitären Umfeld zum Einsatz kommt: Eine Server-Komponente wickelt die Authentifizierung ab und arbeitet ticketbasiert mit SSO-Agenten in den jeweiligen Applikationen zusammen. – Die Kommunikation erfolgt HTTP-basiert über das eigens definierte CAS-Protokoll.

Die Server-Komponenten ist in Form einer Java Webanwendung umgesetzt. Als Client-Komponenten liegen zahlreiche Implementierungen sowohl in Java als auch in PHP, Perl oder ASP vor.

Entwickelt wurde CAS als Opensource-Lösung an der Yale Universität und wird seit Jahren von der JA-SIG Community gepflegt und weiterentwickelt. – Jüngs erfolgte der Sourcerepository-Umzug zu Github um noch stärker die Mitarbeit von der Community zu fördern. Die Dokumentation ist Wiki-basiert.

Wie ist der Single Sign On Mechanismus aufgebaut?

Zentrales Element des Single Sign On Verfahrens ist das Ticket Granting Ticket (TGT), welches der Benutzer erhält wenn er sich gegenüber dem CAS-Server authentifiziert hat. Möchte er sich dann an einer Applikation anmelden, die am SSO teilnimmt, so fragt er ein Service-Ticket am CAS-Server an und präsentiert dieses der Applikation. Darüberhinaus besteht die Möglichkeit mittels Proxy Tickets, Server-side 2nd Hops zu implementieren – d.h. der Zugriff von einem Server auf einen anderen im Namen des aktuellen Benutzers.

Single Sign On Ablauf

Um die Arbeitsweise besser verstehen zu können, dient folgendes Beispiel:

CAS Single Sign On Verfahren

Fordert ein Benutzer unauthentifiziert eine Seite einer Applikation (App1) an (Schritt 1), die am SSO-Verfahren teilnimmt, so wird er mittels eines Redirects (302) auf den CAS-Server umgeleitet (Schritt 2) mit der Bitte den Benutzer für die Applikation App1 zu authentifizieren.
Da er am CAS-Server auch nicht angemeldet ist, erhält er als Antwort dessen Loginmaske (Schritt 3).
Hier muss der Benutzer seine Credentials (Username /Passwort) eingeben (Schritt 4), die dann im CAS-Server validiert werden – sei es gegen eine Datenbank, LDAP oder was auch immer. Im Erfolgsfall stellt der CAS-Server dem Benutzer ein Ticket Granting Ticket aus, dass ihn gegenüber diesem als authentifiziert ausweist. Dies wird ihm als transientes Cookie in der Response zurückgegeben.
Zusätzlich stellt der CAS-Server ein sogenanntes Service-Ticket für die Applikation App1 aus und sendet dieses in einer 302-Response als Parameter an die Applikation zurück (Schritt 5/6).

In der Applikation greift sich ein SSO-Agent (aka CAS-Client) das Ticket ab und versucht dieses nun in einer Server-To-Server Kommunikation gegen den CAS-Server zu validieren (Schritt 7). Gelingt dies, so erhält er die ID des Benutzers zurück für den das Ticket ausgestellt wurde (Schritt 8 ).
Diese ermöglicht es der Applikation ein eigenes Principal-Objekt zu erzeugen, dass den Benutzer für alle folgenden Requests als authentifiziert ausweist (Schritt 9).
Das Aushandeln eines Service-Tickets erfolgt nur beim initialen Request auf die Applikation und ist (in der Standardkonfiguration) auch nur für einen Validierungsaufruf gültig.

Ruft der Benutzer nun einen Link auf einer weiteren am SSO-Verfahren angeschlossenen Applikation (etwa App2) auf, so erfolgt wieder der gleiche Ablauf. Allerdings fallen diesmal die Schritte 3/4 weg, da der Benutzer am CAS-Server bereits authentifiziert ist. Dies wird anhand des mitgesendeten Ticket Granting Cookies sichergestellt.

Spring Security Sample

Um den Aufbau selbst nachspielen zu können, empfiehlt sich das Sample Projekt von Spring Security, welches mit einer fertig konfigurierten Client und Server-Komponente daherkommt und so das einfache Austesten erlaubt.

Zu den Technologien, auf denen das CAS-Projekt aufsetzt und wie dies für die eigenen Bedürfnisse erweitert werden kann, werde ich in einem der nächsten Posts eingehen.

Die Kommentare sind geschlossen.