Einsatz von Single-Sign-On Technologien im Rahmen der Integration von E-Learning Anwendungen

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Einsatz von Single-Sign-On Technologien im Rahmen der Integration von E-Learning Anwendungen Für das Hauptseminar E-Learning Christian Nockemann Toppheideweg 10, Münster Mat.Nr: Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Christian Arndt Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung Single Sign-On Einführung Vor- und Nachteile SSO-Anbieter Shibboleth Kerberos OpenID Evaluation der einzelnen SSO-Anbieter SSO im E-Learning-Kontext Vorteilhaftigkeit von SSO im E-Learning Kontext SSO an der Westfälischen Wilhelms-Universität SSO-Landschaft Kopplung mit dem zentralen Identitätsmanagement der Hochschulverwaltung Praktische Anwendung Implementierung Einsatz und Wartung Fazit und Ausblick Literaturverzeichnis II

3 1 Einleitung Heutzutage sehen sich viele Internet-Benutzer mit einer unüberschaubaren Anzahl von Web-Ressourcen konfrontiert. Die meisten davon haben aus Sicherheitsgründen geschützte Bereiche, auf die nur zugegriffen werden kann, wenn sich der Benutzer zuvor authentifiziert. Demzufolge müssen die meisten Benutzer in der Summe eine sehr große Anzahl von Anmeldedaten (bestehend aus Nutzerkennung und Passwort) verwalten. Diese Entwicklung führt einerseits zu verminderter Benutzerfreundlichkeit, da die Benutzer viel Zeit mit fehlgeschlagenen Login-Versuchen und dem Wiederfinden von Passwörtern verbringen. Andererseits kann es aber auch zu ernsthaften Sicherheitsproblemen kommen. Beispielsweise hinterlegen viele Benutzer ihre Anmeldedaten als Gedächtnisstütze in elektronischer Form auf ihrem Rechner, was von der sicherheitstechnischen Relevanz in etwa mit der Aufbewahrung der Bankkarte und der zugehörigen PIN im gleichen Portemonnaie vergleichbar ist. Des Weiteren werden sehr oft die gleichen Anmeldedaten für verschiedene Web-Ressourcen benutzt, womit ein nicht vertrauenswürdiger Service Anbieter, unter Verwendung dieser Anmeldedaten, weit reichenden Zugriff auf sensible Daten hätte. Auch aus der Sicht von Software-Entwicklern und Administratoren gibt es hier Besserungsbedarf. Die Verwaltung von Benutzerdatenbanken, die Entwicklung von sicheren Anmeldeverfahren sowie das Zurücksetzen von verlorenen Benutzer- Passwörtern sind kosten- und zeitaufwändig. Innerhalb eines Unternehmens oder einer Universität kann es darüber hinaus auch schnell zu inkonsistenten Daten kommen, wenn jede vorhandene Anwendung eine eigene Benutzerdatenbank verwaltet, da bei einer Änderung der Benutzerdaten alle einzelnen Datenbanken aktualisiert werden müssen. Um einen Lösungsansatz für diese Probleme zu finden, ist es nötig, sich über eine Alternative zum klassischen Modell der Authentifizierung (-> jeder Service Anbieter verlangt eine separate Authentifizierung) Gedanken zu machen. Ein weit verbreiteter Ansatz zur Lösung dieser Probleme ist das so genannte Single Sign-On. Das Ziel dieser Ausarbeitung ist es, einen Überblick über die Grundlagen und Konzepte von Single Sign-On zu geben, sowie eine Auswahl von Single Sign-On Anbietern, respektive ihre Software vorzustellen. Dabei wird ein besonderes Augenmerk auf die Single Sign-Ongestützte Integration von E-Learning Anwendungen gelegt. 3

4 2 Single Sign-On 2.1 Einführung Single Sign-On (SSO) ist ein Mechanismus, welcher es dem Benutzer erlaubt, sich mit einer einzigen Anmeldung bei mehreren Service-Anbietern zu authentifizieren. Dabei meldet sich der Benutzer bei einer zentralen, vertrauenswürdigen Authentifizierungs- Autorität (AA) an, die daraufhin für die Authentifizierung des Benutzers bei allen Service-Anbietern (SA) sorgt, die mit dieser AA zusammenarbeiten und bei denen der Benutzer Zugriffsrechte besitzt. Danach erhält der Benutzer Einsicht in die geschützten Inhalte dieser SAs. Man kann dabei client- und serverbasierte SSO-Varianten unterscheiden [Koc07]. Erstere findet meist Anwendung innerhalb von Unternehmen und gewährleistet eine einheitliche Anmeldung bei mehreren auf einem Rechner installierten Programmen. Die zweite Variante kommt zur Anwendung, wenn auf mehrere verteilte Internet- Ressourcen mit einer einzigen Anmeldung zugegriffen werden soll. Da sich diese Ausarbeitung auf den Bereich des E-Learnings konzentriert und es sich dabei um Web- Anwendungen handelt, ist im Folgenden immer das server-basierte gemeint, wenn von SSO die Rede ist. Des Weiteren lassen sich SSO-Techniken nach der Art der Weiterleitung der Benutzerdaten differenzieren: direkt, token-basiert, sofort und temporär [Ope01]. Bei der direkten Weiterleitung werden die Daten des Benutzers, nachdem er sich bei der AA angemeldet hat, von dieser unverändert an die SAs weitergegeben und dort zur Authentifizierung benutzt. Im Falle der token-basierten Weiterleitung gibt die AA nach der Anmeldung nicht die Benutzerdaten weiter, sondern sendet nur ein Token an den Benutzer. Dieses Token ist eine Art Schlüssel, welchen der Benutzer verwenden kann, um Zugriff auf die geschützten Inhalte eines SA zu erhalten, ohne seine Anmeldedaten weitergeben zu müssen. Der SA kann sicher sein, dass ein Benutzer, der ein Token besitzt auch die entsprechenden Zugriffsrechte hat, ohne dass er Einsicht in die Anmeldedaten des Benutzers erhält. 4

5 Bei der sofortigen Anmeldung fungiert die AA als eine Art Anmelde-Proxy für den Zugriff auf die einzelnen SAs. Das heißt, nachdem ein Benutzer sich bei der AA authentifiziert hat, erlangt er direkten Zugang zu den geschützten Ressourcen der SAs, ohne dass Letztere noch irgendwelche Informationen (seien es nun Anmeldedaten oder ein Token) benötigen. Bei der temporären Weiterleitung werden die Benutzerdaten nur eine gewisse Zeit lang bei der AA zwischengespeichert und können so lange für die Anmeldung bei den verschiedenen SA benutzt werden. Wichtig bei dieser Unterscheidung ist, dass diese Kategorien nicht disjunkt sind und dass sich nicht jede SSO-Software eindeutig in eine dieser Kategorien einordnen lässt. Die meisten führenden SSO-Anbieter (z.b. Shibboleth und Kerberos) benutzen allerdings die token-basierte Weiterleitung, teilweise in Kombination mit einer temporären Zwischenspeicherung der Benutzerdaten. Aus diesem Grunde wird im Folgenden detaillierter auf diese Art der Weiterleitung eingegangen. In Anlehnung an [Dec02] Abb.1: Token-basierte Single Sign-On Anmeldung Abb. 1 zeigt den schematischen Aufbau eines token-basierten SSO-Anmeldevorgangs. Dabei wird der grundsätzliche Anmelde-Prozess dargestellt, der tatsächliche Ablauf kann allerdings je nach SSO-Software in den Details davon abweichen (dazu mehr im Abschnitt 2.3). Zunächst meldet sich der Benutzer unter der Verwendung seiner 5

6 Anmeldedaten (1) bei der AA an, woraufhin diese überprüft, ob der Benutzer in der Benutzer-Datenbank vorhanden ist und authentifiziert werden kann (2). Im Falle einer erfolgreichen Authentifizierung sendet die AA ein Token an den Agenten des Benutzers (im Normalfall also an den Browser) zurück (3), welches dieser nun zur Anmeldung bei den einzelnen SAs benutzen kann, die mit der AA zusammenarbeiten (4) [Dec02]. Hierbei ist zu beachten, dass der Agent des Benutzers die Anmeldung und Weiterleitung des Tokens übernimmt, so dass der Benutzer nur für die Anmeldung bei der AA in Aktion treten muss. Die Schritte (2) bis (4) sind demnach transparent für den Benutzer. Wie in Abb1. zu sehen ist, müssen die Service-Anbieter der Authentifizierungs- Autorität vertrauen, dass wirklich nur berechtigte Benutzer Zugriff auf die gesicherten Inhalte erhalten. Auch müssen die Benutzer sicher sein können, dass Ihre Anmeldedaten von der AA nicht missbraucht werden. Darüberhinaus muss gewährleistet werden, dass die Anmeldedaten im Zuge der Übermittlung nicht ausspioniert werden können [Ope01]. Dies ist mit geeigneten Kryptographie-Methoden wie z.b. dem Diffie- Hellman-Schlüsselaustausch [Res99] oder dem RSA-Kryptosystem [Sch02] zu gewährleisten. Nachdem ein Benutzer erfolgreich authentifiziert wurde, muss im nächsten Schritt überprüft werden, über welche Zugriffsrechte er verfügt. Dies geschieht im Rahmen der Autorisierung, welche der Zuweisung [ ] von Zugriffsrechten auf Daten und Dienste an Systemnutzer [Jan04] dient. Im Zuge der Autorisierung wird also überprüft, auf welche Ressourcen ein authentifizierter Benutzer zugreifen darf. Dies geschieht häufig in Form einer Rollenzuweisung. Typische Rollen in E-Learning Anwendungen sind beispielsweise Administrator, Dozent/Korrektor und Student. Wie eine SSO- Anwendung mit der Autorisierung der Benutzer umgeht, ist sehr unterschiedlich. In Abschnitt 2.3 werden drei SSO-Anwendungen vorgestellt, unter anderem wird dort auch darauf eingegangen, wie die Autorisierung der Benutzer vonstatten geht. Es sei auch noch erwähnt, dass einige SSO-Anbieter einen so genannten Single-Sign- Out-Mechanismus unterstützen, der gewährleistet, dass ein Benutzer, der sich bei allen SAs gleichzeitig abmelden möchte, dies auch tun kann. Das macht insbesondere im E- Learning-Kontext Sinn, da bei Benutzung öffentlicher Rechner (z.b. an der Universität) ohne solch einen Mechanismus ein nachfolgender Benutzer Zugriff hätte auf alle SAs, für die sich der vorherige Benutzer per SSO angemeldet hat. Diese Problematik wird in Abschnitt 3.2 genauer erörtert. 6

7 2.2 Vor- und Nachteile Zunächst einmal bleibt festzuhalten, dass einige der in der Einleitung genannten Sicherheitsprobleme wie das Weitergeben von Anmeldedaten an nichtvertrauenswürdige Service-Anbieter mithilfe von SSO gelindert werden können. Andererseits zeigen alle derzeit auf dem Markt verfügbaren SSO-Softwarepakete auch Schwächen in Bezug auf Komfort und Sicherheit. Im Folgenden werden daher die Vorteile und Nachteile von SSO gegenübergestellt. Zu den wichtigsten Vorteilen zählen folgende Punkte: Einheitlicher Zugriff auf Webinhalte mit Hilfe eines einheitlichen Authentifizierungsvorgangs Erhöhung der Benutzerfreundlichkeit Erhöhung der Sicherheit, da die Anmeldedaten nur an eine einzige Authentifizierungs-Stelle weitergegeben werden müssen Es ist nur noch eine Benutzerdatenbank nötig, was den Kosten- und Zeitaufwand für die Benutzerverwaltung reduziert Ebenfalls wird die Datenhaltung dadurch konsistenter, da Änderungen an den Benutzerdaten nicht mehr in mehreren Datenbanken vorgenommen werden müssen Anpassungen am Anmeldeverfahren (z.b. nach einer Änderung des Datenschutzrechts) müssen nur ein mal gemacht werden und nicht bei jedem einzelnen SA Demgegenüber stehen folgende Nachteile [Rum06]: Falls die Zugangsdaten bei der Übertragung zur AA ausgespäht werden, hat der Angreifer Zugriff auf alle SAs, für die der Benutzer über die AA authentifiziert wird Die AA stellt einen Single-Point-Of-Failure dar, denn wenn der Authentifizierungsmechanismus versagt, wird dem Benutzer der Zugriff auf alle teilnehmenden SAs verweigert 7

8 Diese beiden Punkte könnte man allerdings teilweise umgehen. Der Single-Point-Of- Failure ließe sich beheben, indem jeder Service-Anbieter neben der SSO-Anmeldung noch eine alternative, klassische Anmeldung zur Verfügung stellt. Allerdings müsste dann doch wieder pro SA eine eigene Benutzerdatenbank verwaltet werden. Darüberhinaus muss die Authentifizierungs-Autorität gewährleisten, dass die Übertragung der Anmeldedaten des Benutzers so sicher wie möglich ist, zum Beispiel indem Tokens mit einer Gültigkeit versehen werden, damit sie nicht missbraucht werden können, falls es einem Angreifer gelingt ein Token abzufangen [Rum06]. Oder es wird mit geeigneten Kryptographie-Verfahren (siehe Abschnitt 2.1) verhindert, dass ein Angreifer überhaupt die Möglichkeit bekommt, ein Token abzufangen. Grundvoraussetzung dafür, dass der Einsatz von SSO überhaupt Sinn macht, ist, dass es mehr als einen SA gibt, der an der SSO-Infrastruktur teilnimmt. Normalerweise ist diese Voraussetzung aber an Universitäten und in Unternehmen erfüllt. Abschließend lässt sich sagen, dass die Vorteile in den meisten Fällen die Nachteile überwiegen. Um allerdings endgültig die Vorteilhaftigkeit von SSO beurteilen zu können, sollte zunächst eine Übersicht über die wichtigsten SSO-Anbieter verschafft werden, gefolgt von einer Evaluation. 2.3 SSO-Anbieter Shibboleth Shibboleth ist ein Projekt der Internet2-Middleware Initiative mit dem Ziel, eine Open- Source Software zur Verfügung zu stellen, welche den Zugriff auf Web-Ressourcen vereinheitlicht [Shi07]. Es wurde an der Pennsylvania State University (hauptsächlich für den universitären Kontext) entwickelt. Es basiert auf der Security Assertion Markup Language (SAML) welche ein XML-basiertes Framework zur technischen Realisierung von Authentifizierungs-und Berechtigungsverfahren ist [OAS07]. Im Zentrum der Shibboleth-Architektur steht der Austausch von SAML-Aussagen mithilfe des SOAP-Netzwerkprotokolls [W3C07]. Diese Aussagen beinhalten allgemeine Informationen über den Benutzer (wie z.b. ob die Authentifizierung erfolgreich war oder welche speziellen Zugriffsrechte der Benutzer hat) sowie über die Attribute die der Benutzer besitzt [CDS05]. Eine SAML-Aussage welches ein Attribut eines Benutzers weiterleitet hätte z.b. die Form <samlp:attributestatement> einattribut</samlp:attributestatement>. Im Kontext von Shibboleth 8

9 werden Attribute als Eigenschaften des Benutzers verstanden, die mit beliebigem Inhalt, wie z.b. Zugriffsrechten oder Wohnort, gefüllt werden und somit dem SA zur Verfügung gestellt werden können. Damit lässt sich mit ihnen auch die Benutzer- Autorisierung (siehe Abschnitt 2.1) realisieren, indem bei der Anmeldung ein Attribut weitergeleitet wird, welches die Rollenbezeichnung beinhaltet (z.b. Admin oder Student ). Ob und welche Attribute weitergeleitet werden, entscheidet die AA. Da nur Aussagen und keine konkreten Benutzerdaten ausgetauscht werden, kann man hier von einem token-basierten SSO-Mechanismus sprechen, wobei ein so genannter Sicherheitskontext ein Token repräsentiert. Ein Sicherheitskontext ist ein SAML- Konstrukt, welches dem SA garantiert, dass der Benutzer derjenige ist, für den er sich ausgibt, und dementsprechende Zugriffsrechte besitzt. Anders als bei vielen anderen SSO-Anbietern wird bei Shibboleth die Authentifizierungsanfrage nicht zunächst an die AA, sondern direkt an den SA gestellt (und von dort aus an die AA weitergeleitet). D.h. der Benutzer braucht gar nicht wissen, wer die Zuständige AA ist, sondern geht schlicht auf die Homepage des SA, wird von dort auf ein Anmeldeformular der AA und nach erfolgter Anmeldung direkt zur geschützten Ressource weitergeleitet. Grundlegend sind an einem Authentifizierungsvorgang unter Verwendung von Shibboleth drei verschiedene Parteien beteiligt [Can05]. Der Identity-Provider (IdP, übernimmt ähnliche Aufgaben wie die AA), der Service-Provider (SP, ähnlich wie der SA) und der Benutzer (bzw. sein Agent). Darüber hinaus gibt es noch den so genannten Where Are You From? -Service (WAYF), der bei Bedarf den IdP eines bestimmten Benutzers ermitteln kann. Der IdP ist dafür verantwortlich, Aussagen über die Authentifizierung und die Attribute eines Benutzers zu treffen und weiterzuleiten. Der SP stellt Web-Ressourcen zur Verfügung. Der (optionale) WAYF-Service bietet dem SP die Möglichkeit, einen validen IdP für einen Benutzer zu ermitteln. In Abb. 2 ist der schematische Aufbau eines SSO-Vorgangs mit Hilfe von Shibboleth dargestellt. 9

10 In Anlehnung an [CDS05] Abb. 2: Schematischer Aufbau einer Anmeldung mit Shibboleth Wie man sehen kann, sind der SP und der IdP in weitere Komponenten unterteilt. Der SP beinhaltet neben den geschützten Ressourcen auch den sog. Assertion Consumer Service, welcher dafür zuständig ist, einen Sicherheitskontext für den Benutzer zu erstellen, falls letzterer zuvor erfolgreich authentifiziert wurde. Der IdP besteht im Wesentlichen aus dem SSO-Service, welcher für die Authentifizierung des Benutzers verantwortlich ist, sowie der Authentication Authority, welche überprüft, ob ein Benutzer in der Datenbank vorhanden ist und authentifiziert werden kann. Der genaue Ablauf wird im Folgenden schrittweise erklärt. SP und IdP haben auch noch weitere Komponenten, deren Funktionen jedoch für den Überblick, der hier gegeben werden soll, nicht von Belang sind. Bei Interesse sei [CDS05] als weiterführende Lektüre empfohlen. Wenn der Benutzer auf eine Ressource des SP zugreifen möchte (1) (der Benutzer braucht, wie bereits erwähnt, im Unterschied zu den meisten anderen SSO- Anwendungen, nicht zuerst auf den IdP zugreifen), wird er von letzterem an den SSO- Service des IdP (wenn der IdP des Benutzers nicht bekannt ist, kommt hier der oben genannte WAYF-Service ins Spiel, welcher den entsprechenden IdP ermittelt) weitergeleitet (2), wo der Benutzer sich mit seinen Anmeldedaten authentifizieren muss (3). Der SSO-Service leitet die Daten an die Authentication Authority weiter, welche ein Authentifizierungs-Statement zurückgibt, welches wiederum vom SSO-Service in Form einer SAML-Aussage an den Agenten des Benutzers weitergeleitet wird (4). Dieses Statement beinhaltet Informationen über den Erfolg bzw. Misserfolg der 10

11 Authentifizierung des Benutzers. Im nächsten Schritt wird dieses Authentifizierungs- Statement vom Agenten des Benutzers an den Assertion Consumer Service des SP weitergeleitet (5), wo dieses Statement überprüft und gegenebenfalls ein Sicherheits- Kontext erstellt wird (6). Nun versucht der Agent des Benutzers erneut auf die geschützte Ressource zuzugreifen (7), was auch gelingt, wenn ein valider Sicherheits- Kontext vorhanden ist (8) [CDS05]. Die Schritte (3) bis (7) sind transparent für den Benutzer, da der Agent des Benutzers (im Normalfall also der Browser) sie übernimmt. Darüber hinaus wird der von dem Assertion Consumer Service erstellte Sicherheitskontext für eine gewisse Zeit zwischengespeichert, in welcher dem Benutzer die Eingabe der Benutzerdaten beim IdP erspart bleibt und er direkt zur Ziel-Ressource weitergeleitet wird, wenn er erneut auf einen SP zugreift, der mit dem hier betrachteten IdP zusammenarbeitet. Abschließend bleibt noch zu erörtern, was die Vor- und Nachteile von Shibboleth für die Integration von E-Learning Anwendungen sind. Vorteile: Unterstützt weit verbreitete Standards (SAML, XML, SSL, SOAP uvm.) Open-Source Nutzung bereits vorhandener Infrastrukturen: keine eigene Authentifizierung, sondern Nutzung von Apache Webserver und/oder Tomcat Servletengine, sowie Nutzung bereits vorhandener Datenbanken [Ebe06] Sehr intuitiv, da der Benutzer sich direkt beim Service-Anbieter anmeldet und nicht zuerst bei der Authentifizierungs-Autorität Nachteile: Insgesamt eine relativ komplexe Technik: Java, Tomcat und Apache Kenntnisse werden vorausgesetzt Bisher existiert noch kein Single Sign-Out Mechanismus, was gerade im E- Learning Bereich zu Problemen führt, wenn Shibboleth von einem öffentlichen (Uni-) Rechner benutzt wird Kerberos Das Kerberos-Authentifizierungsprotokoll wurde vom MIT (Massachusetts Institute of Technology) entwickelt, um verschiedenen Parteien eine Möglichkeit zu geben, sich 11

12 zuverlässig und sicher gegenseitig zu authentifizieren. Dabei liegt das Hauptaugenmerk auf einer sicheren Kryptographie [Ker07]. Im Speziellen benutzt Kerberos den amerikanischen DES (Data Encryption Standard) [Kel06], der so sensibel ist, dass die Vereinigten Staaten den Export von Kerberos-Implementierungen bis ins Jahr 2000 verboten. Anders als Shibboleth wurde es nicht speziell zur Implementierung eines SSO-Mechanismus entwickelt, sondern für den Authentifizierungsvorgang im Allgemeinen, allerdings lässt es sich sehr komfortabel als SSO-Anwendung nutzen. Das MIT stellt eine kostenlose Implementierung dieses Protokolls zur Verfügung. Grundlegend sind auch bei einem Authentifizierungsvorgang unter Verwendung von Kerberos drei Parteien beteiligt: Principal, Key Distribution Center und der Service Anbieter [Wie08]. Principals sind die einzelnen Nutzer des Authentifizierungsmechanismus und werden im Rahmen von Kerberos über zwei Komponenten und einen Realm identifiziert. Die erste Komponente ist der Benutzername, die (optionale) zweite ist die Rolle. Der Realm gibt die Authentifizierungs-Domäne an (Beispiel: -> Die zweite Komponente kann also zum Zwecke der Autorisierung benutzt werden. Das Key Distribution Center (KDC) besteht aus der Principal Database (speichert Principals und Keys), Authentication Server (AS) und dem Ticket Granting Server (TGS) und ist zuständig für den eigentlichen Authentifizierungsvorgang. Zur Authentifizierung werden bei Kerberos so genannte Tickets benutzt. Der Anmeldevorgang unter Verwendung von Kerberos findet in zwei Stufen statt. In der ersten Stufe wird vom Nutzer ein so genanntes Ticket-Granting-Ticket (TGT) beim KDC angefordert. Mit Hilfe des TGT kann der Benutzer nun im zweiten Schritt Service Tickets (ST) anfordern, mit denen er sich bei den entsprechenden Service-Anbietern anmelden kann. Diese Schritte werden in Abb. 3 schematisch dargestellt. 12

13 In Anlehnung an [Ric08] Abb. 3: Schematischer Aufbau einer Anmeldung mit Kerberos Zunächst fordert der Client unter Angabe seiner Principal-ID (z.b. ein TGT beim Authentication Server des KDC an (1). Ist diese ID in der Principal Database vorhanden, schickt der AS eine Antwort, die das TGT (chiffriert mit dem geheimen Schlüssel des TGS, unter Verwendung des oben genannten DES) und den Session Key (chiffriert mit dem geheimen Schlüssel des Benutzers) beinhaltet (2). Das TGT kann der Client nun verwenden, um damit ein spezielles Service Ticket (ST) beim TGS anzufordern (3) (der TGS kann das TGT mit seinem geheimen Schlüssel dechiffrieren). Neben dem TGT schickt der Client dabei auch einen mit dem Session Key verschlüsselten Authenticator mit, womit er sich gegenüber dem TGS eindeutig identifiziert. Die Antwort des TGS beinhaltet das ST (chiffriert mit dem geheimen Schlüssel des Service-Anbieters) und einen Service Session Key (chiffriert mit dem zuvor vom AS generierten Session Key) (4). Daraufhin versucht der Client nun auf die Ziel-Ressource des Service-Anbieters zuzugreifen (5), und zwar mit Hilfe des zuvor erhaltenen ST und eines weiteren Authenticators (verschlüsselt mit dem vom TGS erhaltenen Service Session Key). Im letzten (optionalen) Schritt (6) identifiziert sich der Service-Anbieter beim Client, damit letzterer sicher sein kann, dass Missbrauch ausgeschlossen ist. Sind alle übergebenen Informationen korrekt, wird dem Benutzer daraufhin der Zugriff auf die Ressource gewährt. [Ric08] 13

14 Anfangs wurde erwähnt, dass Kerberos nicht ausschließlich als SSO-Mechanismus arbeitet. Die Frage ist nun also, wo in diesem Vorgang SSO-Charakteristika zu erkennen sind. Zunächst sind die Tickets den Tokens einer Token-basierten SSO- Anmeldung ähnlich. Darüber hinaus fungiert das spezielle Ticket Granting Ticket als die SSO-typische einmalige Anmeldung bei der Authentifizierungs-Autorität. Des Weiteren können mithilfe des so genannten Ticket Caches bereits erhaltene Service- Tickets auch eine gewisse Zeit lang zwischengespeichert werden, so dass wirklich nur eine einzige Anmeldung nötig ist. Abschließend werden noch die Vor- und Nachteile von Kerberos zusammengefasst: Vorteile: Ausserordentlich starke und sichere Kryptographie (DES, siehe oben) Daher eine sehr sichere gegenseitige Authentifizierung aller beteiligten Parteien Sehr performant wegen der geringen Belastung des KDC, da keine Verbindung zu den einzelnen Service-Anbietern nötig ist [Wie08] Ist bereits als Standard im RFC 1510 festgehalten [Koh93] Nachteile Nicht ohne weiteres mit NAT(Network Address Translation)-Firewalls einsetzbar [Wie08] Es ist sehr aufwändig, vorhandene Web-Applikationen so anzupassen, dass Kerberos eingesetzt werden kann Kein Single Sign-Out Mechanismus vorhanden OpenID OpenID ist ein etwas schlankerer SSO-Standard, dessen Funktionsumfang sich auf die grundlegenden SSO-Mechanismen beschränkt. Das ist vielleicht auch der Grund für die Popularität von OpenID. Viele kleinere Webseiten, Blogs und Communities sowie Yahoo unterstützen und verwenden OpenID bereits. Google, IBM und Microsoft haben verlauten lassen, dass sie planen, OpenID auch einzusetzen [Arr08]. Bei einem Anmeldevorgang unter Verwendung von OpenID sind vier Parteien beteiligt: ein Client, ein OpenID Server, ein Identity Server (manchmal auch Identity Provider 14

15 genannt) und ein Consumer (dieser Begriff ist synonym zu den bereits erwähnten Service-Anbietern zu verstehen). Der OpenID Server sorgt für die eigentliche Anmeldung, während der Identity Server für die eindeutige Identifizierung der Benutzer zuständig ist. In Anlehnung an [Win06] Abb. 4: Schematischer Aufbau einer Anmeldung mit OpenID Für die Anmeldung bei einem Consumer verwendet der Benutzer eine URL (seine so genannte OpenID), die lediglich in ein Formular eingegeben werden muss (1). Diese OpenID-URL schickt der Consumer weiter an einen Identity Server (2), welcher daraufhin eine valide URL zurückgibt, die zum Anmeldeformular des OpenID Servers führt (3). Als nächstes leitet der Consumer den Client zu dieser URL weiter (4), wo der Benutzer sich mit seinen Anmeldedaten einloggen muss (5) (hierbei handelt es sich um das SSO-typische einmalige einloggen bei einer Authentifizierungs-Autorität), gefolgt von einer erneuten Weiterleitung zum Consumer (6), wo dann im Falle einer erfolgreichen Authentifizierung der Zugriff auf die geschützte Ressource gewährt wird (7). OpenID ist zwar mittlerweile sehr weit verbreitet [Kle07], steht allerdings auch stark in der Kritik. Zum einen, weil der Identity Server alle Seiten speichert, für die man sich 15

16 mit seiner OpenID angemeldet hat [Ben07], zum anderen, weil sehr leicht Phishing- Attacken ausgeführt werden können. Für ein anschauliches Beispiel für eine solche Phishing-Attacke sei [Lau07] empfohlen. Die Single Sign-Out Problematik von Shibboleth und Kerberos besteht bei OpenID allerdings nicht, da man nicht automatisch bei allen Consumern angemeldet ist, sobald man sich authentifiziert hat. Mit anderen Worten: Single Sign-Out wird nicht benötigt. Vorteile: Weit verbreitet Leicht anzuwenden auf bereits vorhandene Webseiten Sehr intuitiv, da der Benutzer sich direkt beim Service-Anbieter anmeldet und nicht zuerst bei der Authentifizierungs-Autorität Single Sign-Out Problematik existiert nicht Nachteile: Phishing Attacken möglich Identity Server speichert alle Seiten, für die man sich mit OpenID authentifiziert hat Keine Möglichkeit weitere Benutzerdaten zu übermitteln Bietet nur sehr grundlegende SSO-Funktionen Evaluation der einzelnen SSO-Anbieter Die Frage ist nun, welche der drei Alternativen am besten geeignet ist für die Integration von E-Learning Plattformen. OpenID lässt sich in bereits vorhandene Web-Applications am einfachsten integrieren und ist mittlerweile sehr weit verbreitet. Es hat allerdings gerade im Bereich des E- Learnings signifikante Nachteile. Zum einen besteht die Gefahr von Phishing Attacken, was bei den teilweise sehr sensiblen Daten, die im Hochschulbetrieb ausgetauscht werden (Klausurergebnisse, Studentendaten usw.) sehr problematisch ist. Zum anderen gibt es derzeit keine Möglichkeit, Daten über einen Benutzer (wie z.b. Matrikelnummer 16

17 oder ZIV-ID) zu übermitteln, was aber in den allermeisten Fällen nötig ist. Allgemein verfügt OpenID nur über einen sehr geringen Funktionsumfang. Kerberos und Shibboleth sind zwar deutlich aufwändiger zu installieren und einzusetzen, bieten allerdings einen höheren Grad an Sicherheit sowie einen großen Umfang von Funktionen und sind sogar individuell erweiterbar. Kerberos legt einen besonderen Augenmerk auf die Sicherheit, was sich in einer starken Kryptographie widerspiegelt (siehe Abschnitt 2.3.2). Darüberhinaus ist es sehr performant, da keine Kommunikation zwischen Service-Anbieter und Authentifizierungs-Autorität stattfinden muss. Allerdings kann es zu Problemen kommen, wenn Kerberos in Verbindung mit NAT-Firewalls eingesetzt wird. Shibboleth hingegen bietet die Möglichkeit, beim Anmeldevorgang Attribute zu übermitteln, welche Zusatzinformationen zum Benutzer enthalten (z.b. Matrikelnummer oder adresse). Darüber hinaus ist die Anmeldung mit Shibboleth sehr intuitiv, da der Benutzer nicht zuerst auf die Authentifizierungs- Autorität zugreifen muss, um sich einzuloggen, sondern zuerst die Website des Service- Anbieters aufruft, von der er dann für die Anmeldung zum AA weitergeleitet wird. Die Benutzung weit verbreiteter Standards wie XML und SOAP ist gerade im Forschungsumfeld ein weiterer Pluspunkt. Des Weiteren wird Shibboleth schon an einigen Hochschulen eingesetzt und genießt allgemein ein hohes Ansehen aufgrund seiner offenen Schnittstellen und seiner Konzipierung für den universitären Kontext. Jedoch bietet Shibboleth keinen Single Sign-Out Mechanismus, was insbesondere im E- Learning Umfeld problematisch ist, weil dort häufig Pool-Rechner benutzt werden (siehe Abschnitt 3.2). Es bleibt festzuhalten, dass Kerberos und Shibboleth für die Integration von E-Learning Anwendungen besser geeignet sind als OpenID. Zwar ist Letzteres leichter zu handhaben, scheidet aufgrund seiner Sicherheitsschwächen und geringen Funktionsumfangs aber aus. Sowohl Kerberos als auch Shibboleth bieten (unter Inkaufnahme einiger Schwächen) eine große Zahl von Funktionen und sind gleichermaßen zu empfehlen. 17

18 3 SSO im E-Learning-Kontext 3.1 Vorteilhaftigkeit von SSO im E-Learning Kontext Nachdem in Kapitel 2 SSO im Allgemeinen und drei Anwendungen im Speziellen vorgestellt wurden, soll nun abgewogen werden, wie vorteilhaft SSO bei der Integration von E-Learning Anwendungen ist. Allgemein lassen sich folgende Vor- bzw. Nachteile beim Einsatz von SSO im E- Learning Kontext ausmachen: Vorteile: Höhere Sicherheit Höhere Benutzerfreundlichkeit Bei der Entwicklung neuer E-Learning Anwendungen muss kein Aufwand mehr betrieben werden für die Implementierung eines Authentifizierungsmechanismus [Sto07] Zentralisierte Verwaltung von Benutzerrollen und rechten Einheitliche Benutzerdatenbank Nachteile: Die Integration in eine bestehende E-Learning Landschaft einer Universität kann sehr aufwändig sein [Sto07] Bei der Nutzung kann es zu Sicherheitsproblemen kommen, wenn der Benutzer sich nicht komplett ausloggt (falls kein Single Sign-Out Mechanismus vorhanden ist) Im Folgenden wird nun am Beispiel der Westfälischen Wilhelms-Universität Münster, wo seit einiger Zeit Shibboleth als SSO-System eingesetzt wird, erörtert, ob die Voroder Nachteile überwiegen. 18

19 3.2 SSO an der Westfälischen Wilhelms-Universität SSO-Landschaft Seit 2007 wird Shibboleth an der Westfälischen Wilhelms-Universität (WWU) eingesetzt. Initiiert vom ZIV (die Zentrale Informations-Verarbeitung der WWU) [Sto07] gibt es mittlerweile einige universitäts-interne Anwendungen, die den SSO- Service benutzen. Dabei stellt das ZIV einen Identity-Provider zur Verfügung, so dass auf Seiten der E-Learning Anwendungen nur noch ein Service-Provider installiert werden muss, um den SSO-Service nutzen zu können (genaueres dazu in Abschnitt 3.2.2). Beispielanwendungen, die diesen Service bereits nutzen, sind xlx 2 [Xlx08] und Learnr [Lea07]. Während Studenten und Mitarbeiter zuvor für beide Services jeweils einen eigenen Account anlegen mussten, brauchen sie jetzt nur ihre ZIV-Anmeldedaten, die sie zu Beginn ihres Studiums bzw. Beschäftigungsverhältnisses erhalten haben, angeben, um sich eindeutig als Angehörige der WWU zu identifizieren und Zugriff zu erlangen. In diesem Falle müssen sich die Benutzer also nicht aktiv bei der Autorisierungs-Autorität (dem ZIV) registrieren, da dies automatisch zum Anfang des Studiums bzw. Beschäftigungsverhältnisses geschieht. Mit anderen Worten: jeder Studienanfänger und Mitarbeiter erhält automatisch Zugriff auf alle E-Learning Plattformen, die Shibboleth benutzen. Allerdings bieten beide Anwendungen auch noch eine herkömmliche Authentifizierung, damit sich universitäts-fremde Nutzer ebenfalls einloggen können. Das ist z.b. sinnvoll, wenn Gastdozenten bzw. hörer am Vorlesungsbetrieb teilnehmen. In dieser Konstellation bietet SSO einen weiteren Vorteil: da ausschließlich Studenten und Mitarbeiter der WWU eine ZIV-Kennung erhalten, können die Lehrstühle sicher sein, dass kein unerlaubter Zugriff auf ihre Materialien innerhalb dieser E-Learning Anwendungen stattfindet. Es ist daher nicht mehr nötig, Lehrmaterialien zusätzlich auf andere Art und Weise zu schützen. Allerdings werden auch die Nachteile des SSO deutlich. Zunächst einmal ist nicht zu erwarten, dass in absehbarer Zeit alle an der WWU vorhandenen E-Learning Anwendungen auf Shibboleth migriert werden, da die Umstellung einen tiefen Eingriff in die Authentifizierungs-Mechanismen der einzelnen Anwendungen mit sich bringt. Dass bedeutet, dass Studenten und Mitarbeiter auch in Zukunft noch viele unterschiedliche Accounts verwalten müssen. Darüberhinaus ist das Problem des nicht vorhandenen Single Sign-Outs zu lösen. Beim Logout-Vorgang von xlx2 wird der 19

20 Benutzer beispielsweise darauf hingewiesen, dass trotz des Logouts Personen, die den gleichen Rechner benutzen, immer noch Zugriff auf andere Anwendungen haben könnten (z.b. Learnr), bis die Session beendet, also der Browser geschlossen wird. Nichtsdestotrotz überwiegen die Vorteile hinsichtlich Komfort und Sicherheit. In Zukunft sollen die Benutzerdatenbanken verschiedener Universitäten vernetzt und so etwas wie ein inter-universitäres Shibboleth-Netz entwickelt wird, so dass auch die E- Learning Anwendungen anderer Universitäten über eine einheitliche Anmeldung benutzt werden können - so sind zumindest die Pläne des ZIV Kopplung mit dem zentralen Identitätsmanagement der Hochschulverwaltung Nachdem ein kleiner Einblick in die derzeitige SSO-Landschaft an der WWU gewährt wurde, beschäftigt sich dieser Abschnitt nun mit der Kopplung von SSO-Anwendungen mit dem Identitätsmanagement der Hochschulverwaltung (genauer: des ZIV). Da Shibboleth bereits seit längerer Zeit an der WWU eingesetzt wird, wird es hier als Beispielanwendung herangezogen. Wie in Abschnitt beschrieben, wird für das SSO mit Shibboleth von Seiten des ZIV ein Identity-Provider (IdP) zur Verfügung gestellt. Dieser IdP empfängt Authentifizierungsanfragen von den E-Learning Anwendungen (Service-Provider in der Sprache von Shibboleth), fordert die Benutzer zur Anmeldung auf und leitet sie ggf. weiter zu den geschützten Ressourcen der E- Learning Anwendungen (für eine detaillierte Beschreibung eines Authentifizierungsvorgangs mithilfe von Shibboleth, siehe Abschnitt 2.3.1). Von Seiten der Entwickler einer E-Learning Anwendung wird also nur verlangt, einen Service- Provider (SP) zu installieren, um auf den IdP des ZIV zugreifen zu können. Allerdings ist für die Kommunikation mit diesem IdP ein Zertifikat des ZIV nötig, welches man persönlich anfordern muss. Dieses Zertifikat wird aus Sicherheitsgründen nur an Projekte verteilt, die auch tatsächlich im Vorlesungsbetrieb eingesetzt werden. Ist diese Voraussetzung erfüllt, steht dem Einsatz von Shibboleth unter Verwendung des zentralen Identitätsmanagement des ZIV nichts mehr im Wege. Die Informationen, die dabei übermittelt werden, sind aus datenschutzrechtlichen Gründen allerdings sehr begrenzt. Tatsächlich werden nur der Nachname, die ZIV- Kennung und die Universitäts- -Adresse (in Form von Attributen) bei der Anmeldung eines Benutzers übermittelt. Andere relevante Informationen, wie z.b. 20