5 Minuten Lesezeit (943 Worte)

Make Single Sign-On Great Again

Dienstag, 02. Mai 2017

Im ersten Teil dieser Serie (https://blog.ordix.de/technologien/i-have-a-dream-single-sign-on-intro.html) wurden die Vor- und Nachteile von Single Sign-On (SSO) herausgestellt und die grundlegende Entscheidung für die Single Sign-On Enterprise Lösung „Central Authentication Service" kurz CAS getroffen. In diesem Beitrag wird der Aufbau des CAS und dessen Installation, inklusive grundlegender Konfiguration, erläutert. Hinter dem Namen CAS verbergen sich das CAS-Protokoll und das gleichnamige Produkt, deren Entwicklung von der Yale-Universität initiiert wurde und seit 2004 von JA-SIG/Apereo fortgeführt wird.

Das CAS-Protokoll ist ein ticketbasiertes Authentifizierungsprotokoll, das mit dem Kerberos-Protokoll eine große Ähnlichkeit aufweist. Beim ersten Aufruf des Dienstes (siehe Abb. 1 Schritt 1) muss sich der Benutzer einmalig über eine Webseite, auf die vom Dienst weitergeleitet und die vom CAS-Server bereitgestellt wird, authentifizieren (siehe Abb. 1 Schritt 2 und 3). Nach erfolgreicher Authentifizierung und der internen Validierung des Services (siehe Abb. 1 Schritt 4) erhält der Benutzer ein sogenanntes Ticket Granting Ticket (TGT), welches für eine definierte Zeit gültig ist und das Service Ticket (ST) für den angefragten Dienst (siehe Abb. 1 Schritt 5). Im gleichen Schritt wird der Client an den Service weitergeleitet. Dieser Aufruf erfolgt mit dem Service Ticket (siehe Abb. 1 Schritt 6). Der Dienst validiert das Service Ticket am CAS-Server und generiert im Anschluss einen Session Cookie, den er an Client sendet (siehe Abb. 1 Schritte 7 und 8). Ab jetzt kann der Client den Service regulär mit dem Session Cookie nutzen und der Authentifizierungsvorgang ist abgeschlossen (siehe Abb. 1 Schritt 9).

Abb. 1

Die CAS-Software besteht grundlegend aus zwei Komponenten: dem CAS-Server und dem CAS-Client. Der Server stellt die Authentifizierung und die SSO-Funktion zur Verfügung. Er kann verschiedenen Backends wie z. B. LDAP, Active Directory oder einer Datenbank nutzen und mit deren Hilfe die Authentifizierung durchführen. Außerdem verwaltet er die laufenden Benutzersitzungen und die Gültigkeit der Tickets. Der Client wird in die Applikation, die ihre Authentifizierung mittels CAS durchführen soll, integriert und kommuniziert mit dem CAS-Server, um den Benutzer anzumelden und die Tickets zu validieren.

Zurzeit steht der CAS-Server in Version 5.0.5 zur Verfügung, bei dem es sich um die Referenzimplementierung für das CAS-Protokoll (aktuell Version 3.0.2) handelt. Es stehen Clients (https://apereo.github.io/cas/5.0.x/planning/Architecture.html) unter anderem für den Apache Webserver, Java, .NET, PHP und einige andere Plattformen bzw. Programmiersprachen zur Verfügung. Neben dem CAS-Protokoll werden die gängigen Authentifizierungsprotokolle (https://apereo.github.io/cas/5.0.x/planning/Architecture.html) SAML 1.1 / 2, OpenID / OpenID Connect und OAuth 2.0 unterstützt.

Da das CAS-Protokoll auf dem HTTP-Protokoll basiert und das Service Ticket und das Ticket Granting Ticket in einem Cookie gespeichert werden, eignet sich das Protokoll primär für Web-Applikationen.

Der CAS-Server wird im Quellcode veröffentlicht und muss vor der Installation zunächst kompiliert werden. Um diesen Vorgang zu vereinfachen, kann der CAS-Server mit gradle oder maven übersetzt und deployed werden. Eine Alternative ist die Verwendung eines Docker Images, welcher ebenfalls von den Entwicklern bereitgestellt wird.

ORDIX nutzt das cas-overlay-template (https://github.com/apereo/cas-overlay-template), das den Build-Vorgang des CAS-Servers mittels Maven vereinfacht. Für den erfolgreichen Build werden, neben Maven selbst, die entsprechenden Repositories, die in der pom.xml aufgelistet sind, oder eine bestehende Internetverbindung benötigt. Außerdem muss ein Java-Keystore eingerichtet werden, da in diesem das TLS-Zertifikat und der dazugehörige Schlüssel für die Log-in Webseite gespeichert werden.

Für die Installation mit dem Maven Overlay sind die folgenden Schritte notwendig:

1. Wechseln in das Home-Verzeichnis des Nutzers

$ cd /home/user

2. Generieren des Keystores inklusive Zertifikat

$ keytool -genkey -alias tomcat -keyalg RSA -validity 365 -keystore caskeystore

Enter keystore password: Re-enter new password:

What is your first and last name? [Unknown]: casserver.de

What is the name of your organizational unit? [Unknown]: Abteilung

What is the name of your organization? [Unknown]: Unternehmensname

What is the name of your City or Locality? [Unknown]: Stadt

What is the name of your State or Province? [Unknown]: Bundesland

What is the two-letter country code for this unit? [Unknown]: Nationalitaet

Is CN=pfadzurseite, OU=Abteilung, O=Unternehmensname, L=Stadt, ST=Bundesland, C=Nationalitaet correct? [no]: yes

Enter key password for <tomcat> (RETURN if same as keystore password): Key password is too short - must be at least 6 characters

Enter key password for <tomcat> (RETURN if same as keystore password):

3. Falls nicht schon geschehen: Herunterladen des cas-overlay-templates, entpacken und wechseln in das Verzeichnis

$ wget https://github.com/apereo/cas-overlay-template

$ unzip cas-overlay-template-master.zip

cd cas-overlay-template

4. Um den Keystore zu konfigurieren, muss in die Datei etc/cas/config/application.yml folgendes eingefügt werden:

server:
ssl:

key-store: PFAD/ZUM/KEYSTORE
key-store-password: KEYSTOREPASSWORT
key-password: KEYPASSWORT

5. Anschließend kann der Server mit folgendem Skript gebaut und anschließend direkt gestartet werden

$ ./build.sh run

Wird das Skript build.sh, wie oben beschrieben, mit dem Argument „run" ausgeführt, wird der Server aus dem Quellcode übersetzt und ein war-Archiv erstellt, das dank Spring Boot auch direkt gestartet wird. Soll der Server nicht gleichzeitig gestartet werden, muss das Skript mit dem Argument „package" aufgerufen werden. Nachdem der Server gebaut und gestartet wurde, läuft dieser mit Standardkonfiguration, die nur einen statischen Benutzer (causer), mit dem Passwort „Mellon", zulässt. Ist die Installation erfolgreich verlaufen, kann man sich mit diesem Benutzer unter https://casserver.de/cas/login anmelden.

In der Regel werden umfangreichere Authentifizierungsdienste verwendet, die in der Konfigurationsdatei (https://apereo.github.io/cas/5.0.x/installation/Configuration-Properties.html) separat konfiguriert werden können.

Da der CAS auf dem Spring Framework basiert, sind entsprechende Grundkenntnisse bei der Installation und Fehlersuche hilfreich. Trotz der einfachen Installation durch das Overlay-Template ist CAS ein komplexes Programm, das viele Einstellungsmöglichkeiten bietet. Die Dokumentation ist sehr ausführlich und die unterschiedlichen Möglichkeiten werden verständlich erläutert. Es fehlen aber beispielsweise Hinweise, welche Attribute zwingend benötigt werden und welche lediglich optional sind. Darüber hinaus würden Beispiele es vor allem Neulingen erleichtern CAS zu verwenden.

Fortsetzung folgt …