Technologien

Hauptmenü

Förderung durch

Technologien

Central Authentication Service (CAS)

Der Central Authentication Service (CAS) der Java Architecture Special Interest Group (JA-SIG) definiert eine Architektur zur zentralen Authentifikation von Benutzern. Er erlaubt ein Single Sign On (SSO). Das primäre Ziel bei der Entwicklung von CAS war, keine Passwörter mehr an Softwaresysteme zu versenden. Statt dessen werden Benutzer ausschließlich beim zentralen CAS-Server authentifiziert und erhalten dann ein sog. Token, mit dem sie ihre Identität gegenüber anderen Softwaresystemen nachweisen können.

Zusammenfassend stellt der Dienst CAS eine SSO-Architektur bereit. Im Gegensatz zu Shibboleth wird keine Autorisierung angeboten. Eine ähnliche Technologie zu CAS ist Kerberos.

Konzeptionelle Beschreibung

Wir nehmen ein einfaches Anwendungsszenario an: Ein Benutzer möchte auf zwei geschützte Dienste, beispielsweise Wissensorganisation (s1) und Dokumentenserver (s2), zugreifen.

Der Benutzer ruft die geschützte Anwendung (genannt Service) s1 auf. Von dort aus wird er immer an die Anmeldeseite des CAS-Dienstes verwiesen. Dort gibt der Benutzer seine user-ID und sein Passwort ein. Die Daten werden vom CAS-Dienst überprüft und der Benutzer erhält bei Erfolg zwei Tickets: ein Ticket Granting Ticket (TGT), um dem CAS-Dienst seine Identität zu beweisen, und ein Service Ticket (ST), um auf s1 zuzugreifen. Mit diesen Daten wird er zurück an s1 verwiesen. Der Service s1 prüft das vom Benutzer vorgelegte ST. Dazu sendet er es an den CAS-Dienst mit der Bitte um Prüfung. Dort wird das Ticket "entwertet" (kann also nicht nochmals benutzt werden) und der Service erhält als Antwort den Benutzernamen übermittelt. Damit ist der Benutzer authentifiziert und darf auf s1 zugreifen.

Nun möchte der Benutzer auf den Service s2 zugreifen. Er ruft wieder die Anwendung auf und wird an den CAS-Dienst verwiesen. Der CAS-Dienst erkennt nun das TGT und stellt dem Benutzer ohne weitere Rückfragen ein ST für s2 aus. Damit sendet er den Benutzer mit dem ST wieder an s2 zurück. Für den Service s2 ist es nicht weiter von Belang, ob der Benutzer beim CAS-Dienst seine ID und Passwort eingegeben hat oder bereits ein TGT besitzt. S2 prüft wieder das ST und sieht den Benutzer dann als authentifiziert an

Nun wird das Anwendungsszenario erweitert (vgl. Webseite CAS): Der Benutzer möchte per Web-Interface auf seine E-Mails zugreifen. Dazu muss er sich am Webinterface anmelden und dieses muss die Mails von einem Mailserver holen.

Der Benutzer ruft nun das Webinterface auf, erhält vom CAS-Service ein ST und reicht dies an den das Webinterface weiter. Eigentlich müsste das Webinterface Benutzer-ID und Passwort an den Maildienst liefern, um auf die Daten zugreifen zu dürfen. Aber die kennt das Webinterface ja gar nicht. Es kann auch nicht das ST an den Maildienst weiterleiten, weil das ja nach einmaliger Benutzung (Überprüfung) verfallen ist. Also tauscht das Webinterface das ST gegen ein Proxy Granting Ticket (PGT) beim CAS-Dienst ein. Mit dem PGT kann es stellvertretend für den Benutzer sog. Proxy Tickets (PT) beim CAS-Dienst anfordern. Mit einem solchen PT zur Authentifizierung greift das Webinterface nun auf den Maildienst zu.

Zum Konzept gehören noch einige Hinweise und Sicherungen. Das TGT verfällt nach einer einstellbaren Zeit. Dann kann der Benutzer mit seinem TGT keine neuen ST mehr anfordern. Statt dessen muss er erneut User-ID und Passwort eingeben. Sobald der Benutzer sich beim CAS-Dienst explizit abmeldet, sind alle seine Tickets ungültig. Auch die ausgestellten PGTs sind ungültig, so dass die Proxy-Services hiermit keine neuen PTs mehr anfordern können.

Technische Beschreibung

Die Beispielsoftware gliedert sich in einen Server-Dienst und verschiedene Clients. Wir betrachten hier vorrangig den Server-Dienst. Er ist in Java geschrieben und kann in einem beliebigen, konformen Servlet-Container betrieben werden - z. B. Apache Tomcat. Um sich in bestehende Installationen besser einzufügen, werden die eigentlichen Benutzerdaten von einem externen System bezogen. Hier sind unterschiedliche Adapter (z. B. simple Datenbank, LDAP) und ein Java-Interface vorhanden. Jeder Admin kann also selbst eine solche Schnittstelle gegen das mitgelieferte Interface programmieren. Auf "der anderen Seite" liefert der Dienst seine Seiten per HTTP aus. Dies ist bei Daten wie user-ID und Passwort ein erheblicher Sicherheitsmangel, weshalb hier HTTPS eingesetzt werden muss. Dies ist aber nicht mehr in der Verantwortung von CAS, sondern muss vom Servletcontainer oder einem vorgeschalteten Webserver erledigt werden.

'Die Clients exisiteren in größerer Zahl für völlig unterschiedliche Anwendungen: z. B. Webseiten im Apache httpd, Authentifikation in UNIX-Systemen (PAM-Modul), Webseiten in Servletcontainern (JSP, Servlet). Grundsätzlich muss nur der CAS-Server als URL eingetragen werden.

Das TGT ist ein sog. Browser-Cookie, das nur vom CAS-Dienst gelesen werden darf. Falls der Benutzer grundsätzlich keine Cookies annimmt, muss er sich bei jedem Aufruf eines geschützten Dienstes erneut mit user-ID und Passwort authentifizieren. Diese Benutzer können CAS also verwenden, aber mit Cookies wäre es komfortabler. Das ST ist eine Zufallszahl, die per GET-Parameter an die URL angehängt wird. Der Service sendet diese an einen speziellen Dienst des CAS-Servers und erhält ein XML-Fragment zurück, in dem entweder eine Ablehnung oder der Benutzername steht. Die Verweise zwischen Service und CAS-Dienst erfolgen als HTTP-Befehl "redirect". Nach unseren Erfahrungen ist keine Verzögerung wahrnehmbar, wenn wir als authentifizierte Benutzer auf einen anderen Service zugreifen.

Der Mechanismus "Proxy-Authentifikation" ist etwas komplexer aufgebaut. Der Service muss hierzu über einen Dienst verfügen, auf dem er PGTs annehmen kann. Er sendet das ST des Benutzers zusammen mit dem Wunsch nach einem PGT an den CAS-Server. Nachdem das ST erfolgreich geprüft wurde, sendet der CAS-Server das PGT an den Service. Damit werden nun PTs beim CAS-Server angefordert. Der besitzende Dienst des PGT kann also keine PTs selbst ausstellen, sondern muss sie beim CAS-Server anfordern. Ein PT wird genau so benutzt, wie ein ST.

Die Sicherheit des Benutzers ist bei einem solchen, zentralen System immer sehr wichtig. Daher sind alle ST und PT Einweg-Tickets. Technisch führt der CAS-Server eine Liste, welche Tickets er ausgestellt hat. Sobald ihm diese zur Prüfung vorgelegt werden, wird das Ticket aus der "gültigen" Liste entfernt. Wenn der Benutzer sich beim CAS-Dienst abmeldet, so werden alle seine Tickets (ungebrauchte ST und PT, alle PGT) verworfen, also nicht mehr positiv geprüft. Mit einem ungültigen Ticket kann der anfragende Service nichts anfangen, da er auch keinen Benutzernamen erhält.

Ressourcen

Webseite mit Spezifikation: http://www.ja- sig.org/products/cas/overview/protocol/index.html

Webseite CAS (Beispielserver, viele Clients, Spezifikationen): http://www.ja- sig.org/products/cas/index.html

Zu Favoriten hinzufügen

Shibboleth - Einführung

Shibboleth® ist ein von Internet2 Middleware Initiative/Middleware Architecture Committee for Education (MACE) entwickeltes Verfahren zur verteilten Authetifizierung und Autorisierung von Webanwendungen und Webservices (single sign-on). Das in Java implementiertes und als freie Software(open source) verfügbares Packet gestattet es dem Benutzer sich nur einmal bei einer Heimeinrichtung zu identifizieren, um dann ortsunabhängig auf Dienste oder andere lizensierte Inhalte verschiedener Anbieter zugreifen zu können.

Die Stärke des Shibboleth-Systems beruht im Großteil auf der flexiblen Übertragung der Benutzeranttribute über OASIS' Security Assertion Markup Language(SAML), einer auf XML basierten Sprache zur Beschreibung und Übertragung von Sicherheitsrelevanten Daten. Mit dieser Technik ist Shibboleth in der Lage nur die für die Autorisation wirklich benötigten Daten dem Web-Service zur Verfügung zu stellen(Attribute-based-Authorisation).

Die Architektur von Shibboleth besteht aus folgenden 3 Teilen:

Identity Provider - Dieser Dienst befindet sich auf dem Heimserver und dient als eine Schnittstelle zwischen Shibboleth und dem auf dem Heimserver verwendeten Authentifizierungsdienst
Service Provider - Wird beim Anbieter des genutzten Web-Services installiert und verwaltet Zugriff auf die einzelnen Resourcen und den Authetifizierungsvorgang
Lokalierungsdienst - Der sogenannte Where-Are-You-From(WAYF)-Dienst beinhaltet alle Heimserver. Mit Hilfe dieses Dienstes wählt der Benutzer seinen Heimserver, zu dem er dann umgeleitet wird, um den Authentifizierungsvorgang zu vollziehen.

Der Ablauf der Authentifizierung und der Autorisierung wird mit folgender Skizze erläutert(quelle:Phillip Krümmelbein, Authentifizierungs-/Autorisierungsdienste im Vergleich - CAS, Shibboleth und Kerberos):

Shibboleth Architektur

Shibboleth findet hauptsächlich in der Wissenschaft und Lehre Anwendung, aber auch namhafte Firmen wie Microsoft und Novell beginnen, Shibboleth in ihren Web-Anwendungen zu integrieren. Shibboleth kann sowohl bilateral als auch in einem größeren Umfeld eingesetz werden. Ab einer bestimmten Größe übernehmen die sogenannten Föderationen die Organisation und technische Unterstützung. In Deutschland ist DFN-AAI eine solche Föderation, die von dem Deutschen Forschungsnetz(DFN) gegründet wurde und zu der auch Mistel-Projekt angehört.

Weitere Informationen:

Zu Favoriten hinzufügen

Shibboleth - Details

Durch den Einsatz von Shibboleth soll es Benutzern verschiedenster netzwerkgestützter Dienstleistungen ermöglicht werden, diese organisationsübergreifend und durch einmaliges Anmelden nutzen zu können (Single-Sign-On System). Der Datenschutz soll dabei besondere Beachtung erhalten.

Wenn sich Organisationen wie etwa Hochschulen entschließen, gemeinsam Shibboleth zu benutzen, um damit ihren Benutzern Dienste organisationsübergreifend zur Verfügung zu stellen, entsteht eine Föderation. Shibboleth unterstützt Föderationen durch leicht erweiterbare Methoden des Managements und der Verteilung von Konfigurations- und Sicherheitsinformationen über viele Organisationen. Es wird auch ein breites Spektrum an möglichen Benutzerattributen bereitgestellt. Shibboleth unterscheidet dabei nach Nutzern und Dienstanbietern. Die Administration von Nutzeridentitäten und -attributen ist Aufgabe der jeweiligen „Heimatorganisation“, im Folgenden als Identity Provider bezeichnet. Im Universitätsumfeld tritt als Provider in der Regel die Universität auf, bei der der Nutzer immatrikuliert ist. Der Dienstanbieter wird im Weiteren Service Provider genannt.

Die Architektur von Shibboleth besteht aus mehreren Komponenten, die sowohl bei den Service Providern, als auch bei den Identity Providern angesiedelt sind. Vorab sollen diese kurz beschrieben werden, bevor dann ihre Interaktion im Detail dargestellt wird. Auf Seiten eines Identity Providers werden dabei die folgenden beiden Komponenten betrieben:

Zu Favoriten hinzufügen