Central Authentication Service

Central Authentication Service (CAS)^[1] ist ein föderiertes Identitätsmanagement, das ursprünglich von der Yale-Universität entwickelt wurde. Mittlerweile ist CAS ein Projekt des JA-SIG / Apereo Konsortiums, das zum Ziel hat, Universitäten und andere höhere Bildungsinstitute zu vernetzen um einen freien Austausch von Wissen und Technologien zu gewährleisten. Die Funktionalität von CAS ist grundsätzlich mit Shibboleth vergleichbar, lediglich in der Umsetzung gibt es gewisse Unterschiede.

Technik

Für eine Identitätsmanagement-Lösung mit CAS wird ein Central Authenticate Server benötigt. Dieser Central Authenticate Server ist eine Web-Applikation, die das Anmelde- und Authentifizierungs-Prozedere übernimmt. Dabei werden drei URLs benötigt, mit welchen das Anmelde- und Authentifizierungs-Prozedere jeweils durch eine verschlüsselte HTTP-Verbindung (HTTPS-Verbindung) zu dem Central Authentication Server abgewickelt wird.

Ablauf einer Benutzeranmeldung

Login URL: Bei der Anmeldung an dem gewünschten Web Service wird der Browser des Benutzers inklusive einer Service-URL, welche den CAS Client Web Service eindeutig kennzeichnet, automatisch auf die Login-URL des Central Authenticate Servers weitergeleitet. Hier findet die eigentliche Authentifizierung statt, indem der Benutzername und das Passwort abgefragt und geprüft werden. Wenn diese Authentifizierung erfolgreich war, leitet der CAS Server auf die angegebene Service-URL zurück und hängt einen ticket-Parameter mit an. Der ticket-Wert ist ein eindeutiger Login-Token für den angemeldeten Benutzer.^[2]

Validation URL: Der CAS Client Web Service validiert das erhaltene Ticket und die Service-URL über die CAS Server Validation URL. Dabei prüft der Central Authenticate Server, ob das erhaltene Ticket bereits in seiner Datenbank vorhanden ist. Um die Validierung erfolgreich abzuschließen, muss der Server dem Web Service bestätigen, dass das Ticket bereits vorhanden ist, worauf der Zugriff auf den Web Service freigegeben wird. Als Antwort (HTTP response) sendet der CAS Server ein Response Dokument (CAS XML oder SAML XML) an die CAS Client Applikation zurück. Das Response-Dokument enthält mindestens den Benutzernamen des angemeldeten Benutzers bei erfolgreicher Validierung.

Logout URL: Bei Zugriff auf die CAS Server Logout-URL prüft der CAS Server anhand des übergebenen CAS TGT-Cookies, ob der Benutzer angemeldet ist und invalidiert das CAS TGT Ticket sowie das Cookie. Falls der CAS Server sowie die verbundenen CAS Client Applikationen (Web Services) das optionale Single-Sign-Out Protokoll unterstützen, wird ein Benutzer mit diesem Zugriff automatisch bei allen besuchten CAS Client Web Services abgemeldet.

CAS Server Implementierungen

Das CAS Protokoll ist ein offenes Protokoll, zu dem folgende CAS Server Implementierungen bekannt sind:

JASIG CAS Server Referenz-Implementierung^[3]
RubyCAS^[4]

Weblinks

JA-SIG Central Authentication Service

Einzelnachweise

↑ jasig.github.io: Enterprise Single Sign-On (Memento vom 10. September 2014 im Internet Archive) (englisch)
↑ Central Authentication Service (CAS). Apereo Foundation, 19. September 2022, abgerufen am 19. September 2022.
↑ CAS | Apereo. Abgerufen am 19. September 2022.
↑ RubyCAS-Server. RubyCAS, 1. September 2022, abgerufen am 19. September 2022.

[1] sig.github.io: Enterprise Single Sign-On (Memento vom 10. September 2014 im Internet Archive) (englisch)

[2] Central Authentication Service (CAS). Apereo Foundation, 19. September 2022, abgerufen am 19. September 2022.

[3] CAS | Apereo. Abgerufen am 19. September 2022.

[4] RubyCAS-Server. RubyCAS, 1. September 2022, abgerufen am 19. September 2022.

[1]

[2]

[3]

[4]