Central Authentication Service

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten auf deiner Diskussionsseite.

Central Authentication Service (CAS) ist ein föderiertes Identitätsmanagement, welches ursprünglich von der Yale Universität entwickelt wurde. Mittlerweile ist CAS ein Projekt des JA-SIG Konsortiums, welches 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.

[Bearbeiten] Technik

Für eine Identitätsmanagement Lösung mit CAS wird Central Authenticate Server benötigt. Dieser Central Authenticate Server ist im Prinzip ein HTTP-Server, auf dem Java Servlets (serverseitige Java-Applets) laufen, die das Anmelde- und Authentifizierungs-Prozedere übernehmen. 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.

[Bearbeiten] Ablauf einer Benutzeranmeldung

1. Login URL Bei der Anmeldung an dem gewünschten Web Service wird der Browser des Benutzers inkl. einer ServiceID, welche den 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, bekommt der User ein Ticket.

2. Validation URL Anhand der ServiceID wird der Benutzer mit dem vorher erhaltenen Ticket nun wieder zu seinem gewünschten Web Service zurückgeleitet. Der Web Service validiert das erhaltene Ticket und die ServiceID über die Validation URL. Dabei prüft der Central Authenticate Server, ob das erhaltene Ticket bereits in seiner Datenbank vorhanden ist. Um die Validierung erfolgreich abzuschliessen muss der Server dem Web Service bestätigen, dass das Ticket bereits vorhanden ist, worauf der Zugriff auf den Web Service freigegeben wird.

3. Logout URL Die Logout URL ist optional und würde ein Ticket ungültig machen, womit man mit einem Klick bei allen Web Services abgemeldet wäre. Optional ist diese URL deshalb, weil man die Lebensdauer von Tickets schon bei der Erstellung begrenzen kann. Dennoch ist die Logout URL bei sicherheitsrelevanten Anwendungen empfehlenswert.