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

Präsentation zum Thema: "Einsatz von Single-Sign-On Technologien im Rahmen der Integration von E-Learning Anwendungen Christian Nockemann."—  Präsentation transkript:

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

2 3. SSO im E-Learning Kontext 4. Live Demo 5. Fazit
Agenda 1. Einleitung 2. Single Sign-On 3. SSO im E-Learning Kontext 4. Live Demo 5. Fazit Freitag, 16. März 2008

3 Unüberschaubare Anzahl von Web-Ressourcen
Einleitung Unüberschaubare Anzahl von Web-Ressourcen Jeweils eigene Anmeldeverfahren Probleme aus Sicht der Benutzer: Geringe Benutzerfreundlichkeit Sicherheitsprobleme Probleme aus Sicht der Admins/Entwickler: Kosten-/Zeitaufwändige Verwaltung von Benutzerdaten Inkonsistente Datenhaltung Aufwändige Entwicklung und Änderung von sicheren Anmeldeverfahren Unüberschaubare Anzahl von Web-Ressourcen -> mit jeweils geschützten Bereichen Jeweils eigene Anmeldeverfahren Probleme aus Sicht der Benutzer: Geringe Benutzerfreundlichkeit -> große Anzahl von Anmeldedaten (bestehend aus Nutzerkennung und PW) -> Login-Versuche, verlorene PWs Sicherheitsprobleme -> Aufgeschriebene PWs (Bankdaten im Protemonnaie), Daten könnten von SA eingesehen werden Probleme aus Sicht der Admins/Entwickler: Kosten-/Zeitaufwändige Verwaltung von Benutzerdaten -> z.B. Zurücksetzen von Nutzerdaten Inkonsistente Datenhaltung -> Änderungen der Nutzerdaten müssen in allen DBs erfolgen Aufwändige Entwicklung und Änderung von sicheren Anmeldeverfahren -> z.B. bei verändertem Datenschutzrecht Freitag, 16. März 2008

4 Einmalige Anmeldung bei Authentifizierungs-Autorität (AA)
Single Sign-On Einmalige Anmeldung bei Authentifizierungs-Autorität (AA) Authentifizierung bei mehreren Service-Anbietern (SA) Zwei Varianten[Koc07]: Client-basiert Server-basiert Weiterleitung der Benutzerdaten [Ope01]: direkt token-basiert unmittelbar temporär Einmalige Anmeldung bei Authentifizierungs-Autorität (AA) –> AA übernimmt die Authentifizierung bei den SAs Authentifizierung bei mehreren Service-Anbietern (SA) -> die mit der SA zusammenarbeiten Zwei Varianten[Koc07]: Client-basiert -> Einheitlicher Zugriff auf installierte Programme auf einem Rechner Server-basiert -> Zugriff auf mehrere verteilte Internet-Ressourcen Weiterleitung der Benutzerdaten [Ope01]: direkt token-basiert unmittelbar Temporär -> disjunkt, Anbieter lassen sich nicht eindeutig zuordnen, die meisten sind token-basiert, teilweise temporär zwischengespeichert Freitag, 16. März 2008

5 Token-basierte Weiterleitung [Dec02]
Grundsätzlicher Anmeldeprozess -> tatsächlicher Ablauf kann abweichen je nach Anbieter. (2)-(4) sind transparent für den Benutzer. Vertrauen zwischen den Parteien Freitag, 16. März 2008

6 Autorisierung und Single Sign-Out
Geschieht meist nach der Authentifizierung „Zuweisung […] von Zugriffsrechten auf Daten und Dienste an Systemnutzer“ [Jan04] Single Sign-Out Gleichzeitige Abmeldung bei allen Service-Anbietern Wichtig bei der Benutzung öffentlicher Rechner Autorisierung: -> Rollen (z.B. Dozent, Student,…) Geschieht meist nach der Authentifizierung „Zuweisung […] von Zugriffsrechten auf Daten und Dienste an Systemnutzer“ [Jan04] Single Sign-Out Gleichzeitige Abmeldung bei allen SAs Wichtig bei der Benutzung öffentlicher Rechner Freitag, 16. März 2008

7 Authentifizierungsprotokoll Starke Kryptographie [Ker07]
Kerberos Authentifizierungsprotokoll Starke Kryptographie [Ker07] Authentifizierung mit so genannten Tickets Drei Parteien [Wie08]: Principal (z.B. Key Distribution Center (KDC) Principal Database Authentication Server (AS) Ticket Granting Server (TGS) Service-Anbieter Authentifizierungsprotokoll -> für sichere gegenseitige Authentifizierung, nicht explizit für SSO Starke Kryptographie -> Amerikanischer Data Encryption Standard (DES) Drei Parteien: Principal (z.B. -> -> Autorisierung Key Distribution Center (KDC) -> verantwortlich für den eigentlichen Authentifizierungsvorgang Principal Database Authentication Server (AS) Ticket Granting Server (TGS) Service-Anbieter Authentifizierung mit so genannten Tickets Freitag, 16. März 2008

8 Anmeldung mit Kerberos
Bei allen Transaktionen werden chiffrierte Session Keys mitgeschickt (2) Antwort ist chiffriert mit dem Schlüssel des TGS (3) TGS dechiffriert das TGT mit seinem Schlüssel Freitag, 16. März 2008

9 Vor- und Nachteile von Kerberos
Vorteile: Sichere Kryptographie Performant [Wie08] Im RFC 1510 festgehalten Nachteile: Nicht ohne weiteres mit NAT-Firewalls einsetzbar [Wie08] Anpassung bereits vorhandener Web-Applikationen ist sehr aufwändig Kein Single Sign-Out Mechanismus Vorteile: Sichere Kryptographie Performant [Wie08] -> keine Verbindung zwischen KDC und SA nötig Im RFC 1510 festgehalten [Koh93] Nachteile: Nicht ohne weiteres mit NAT-Firewalls einsetzbar [Wie08] Anpassung bereits vorhandener Web-Applikationen ist sehr aufwändig Kein Single Sign-Out Mechanismus Freitag, 16. März 2008

10 Beschränkt sich auf grundlegende SSO-Funktionen
OpenID Sehr populär [Arr08] Beschränkt sich auf grundlegende SSO-Funktionen Vier Parteien: Client OpenID Server Identity Server Consumer Sehr populär [Arr08] -> Viele private Webseiten und Blogs, Yahoo, bald IBM/Microsoft/Google Beschränkt sich auf grundlegende SSO-Funktionen -> z.B. keinerlei Autorisierungsmechanismus Vier Parteien: Client OpenID Server -> eigentliche Anmeldung Identity Server -> Identifizierung des Benutzers Consumer -> Service-Anbieter Freitag, 16. März 2008

11 Anmeldung mit OpenID Freitag, 16. März 2008

12 Vor- und Nachteile von OpenID
Vorteile: Weit verbreitet Auch bei bereits vorhandenen Webseiten leicht einzusetzen Sehr intuitiv, da Benutzer sich direkt beim Consumer anmeldet Single Sign-Out Problematik existiert nicht Nachteile: Phishing Attacken möglich [Lau07] Identity Server speichert besuchte Seiten [Ben07] Keine Autorisierungsfunktion Nur grundlegende SSO-Funktionalität Freitag, 16. März 2008

13 Basiert auf der Security Assertion Markup Language (SAML) [OAS07]
Shibboleth Basiert auf der Security Assertion Markup Language (SAML) [OAS07] Vier Parteien: Client Identity Provider (IdP) SSO-Service Authentication Authority Service Provider (SP) Assertion Consumer Service Where Are You From? (WAYF) Unterstützt Weiterleitung von Attributen Basiert auf der Security Assertion Markup Language (SAML) [OAS07] Vier Parteien: Client Identity Provider (IdP) SSO-Service -> Eigentlicher SSO-Vorgang Authentication Authority -> überprüft ob Benutzer in DB vorhanden ist Service Provider (SP) Assertion Consumer Service -> erstellt Sicherheitskontext, falls Benutzer authentifiziert wurde Where Are You From? (WAYF) Unterstützt Weiterleitung von Attributen -> Autorisierung Freitag, 16. März 2008

14 Anmeldung mit Shibboleth
(1) Zugriffsversuch (Wichtig: direkt beim SA nicht zuerst beim IdP) (2) Weiterleitung zum IdP (3) Anmeldung (4) Erfolg/Misserfolg der Authentifizierung (Authentifizierungsstatement) (5) Authentifizierungsstatement wird überprüft (6) Sicherheitskontext (7) Zugriff (8) Gewährt (3) – (7) sind transparent für Benutzer (Browser übernimmt das) Freitag, 16. März 2008

15 Vor- und Nachteile von Shibboleth
Vorteile: Verbreitete Standards: SAML, XML, SOAP, SSL, uvm. Nutzung bereits vorhandener Infrastrukturen [Ebe06] Intuitiv, da Benutzer zunächst auf den Service-Anbieter zugreift Nachteile: Aufwändige Anpassung bereits vorhandener Web-Ressourcen Kein Single Sign-Out Freitag, 16. März 2008

16 Evaluation der SSO-Anbieter
OpenID: Leicht anwendbar, weit verbreitet Sicherheitslücken, geringer Funktionsumfang Kerberos: Hoher Grad an Sicherheit, Performant Aufwändige Anpassung, kein Single Sign-Out Shibboleth: Flexibel, Offene Schnittstellen → Kerberos und Shibboleth sind für das E- Learning Umfeld am besten geeignet OpenID: Leicht anwendbar -> Sowohl für Entwickler als auch für Benutzer Sicherheitslücken, Geringer Funktionsumfang Kerberos: Hoher Grad an Sicherheit (Kryptographie), Performant (keine Verbindung zwischen KDC und SA) Aufwändige Anpassung, kein Single Sign-Out Shibboleth: Flexibel (Attribute), Offene Schnittstellen (weit verbreitete Standards) Freitag, 16. März 2008

17 Vorteilhaftigkeit von SSO im E-Learning Kontext
Vorteile: Einheitlicher Authentifizierungsvorgang Benutzerfreundlichkeit Sicherheit Reduzierter Aufwand für Benutzerverwaltung Nachteile: Ermöglicht unerlaubten Zugriff auf viele SAs, wenn Anmeldedaten ausgespäht werden Single-Point-Of-Failure Nur wenige Anbieter unterstützen Single Sign-Out Vorteile: Einheitlicher Authentifizierungsvorgang Benutzerfreundlichkeit -> weniger fehlgeschlagene Login-Versuche und verlorene Passwörter Sicherheit -> Anzahl der Passwörter reduziert; SA können Anmeldedaten nicht einsehen (token-basiert) Reduzierter Aufwand für Benutzerverwaltung -> einheitliche Benutzerdatenbank; konsistente Datenhaltung; weniger Aufwand für die Erstellung/Anpassung von Anmeldeverfahren Nachteile: Ermöglicht unerlaubten Zugriff auf viele SAs, wenn Anmeldedaten ausgespäht werden -> Kryptographie Single-Point-Of-Failure Nur wenige Anbieter unterstützen Single Sign-Out Grundvoraussetzung für SSO Einsatz -> mehrere teilnehmende SAs Freitag, 16. März 2008

18 Seit 2006 wird Shibboleth eingesetzt (initiiert vom ZIV)
SSO an der WWU Seit 2006 wird Shibboleth eingesetzt (initiiert vom ZIV) ZIV stellt IdP zur Verfügung Anwendungen die den Service bereits nutzen: Learnr (learnr.uni-muenster.de) xLx (xlx.uni-muenster.de) Anmeldung mit ZIV-Kennung und Passwort Seit 2006 wird Shibboleth eingesetzt (initiiert vom ZIV) -> eigentlich nur Testbetrieb ZIV stellt IdP zur Verfügung -> Von Seiten der E-Learning Anwendungen muss nur noch ein SP installiert werden Anwendungen die den Service bereits nutzen: Learnr (learnr.uni-muenster.de) xLx (xlx.uni-muenster.de) Anmeldung mit ZIV-Kennung und Passwort -> Automatisch bei Immatrikulation/Beginn des Beschäftigungsverhältnisses Vorteile: Benutzerfreundlichkeit/Sicherheit werden sichtbar Nachteile aber auch: Kein Single Sign-Out, wegen komplizierter Anpassung: nicht viele vorhandene Anwendungen wollen es benutzen Freitag, 16. März 2008

19 Kopplung mit dem Identitätsmanagement des ZIV
IdP des ZIV empfängt und bearbeitet Authentifizierungsanfragen Voraussetzungen für die Nutzung des SSO-Services: Installation eines SP Zertifikat des ZIV Übermittelte Attribute: Nachname Universitäts- -Adresse ZIV-Kennung Verwendung der Benutzerdatenbank des ZIV IdP des ZIV empfängt und bearbeitet Authentifizierungsanfragen -> Weiterleitung zu einer Anmeldung Voraussetzungen für die Nutzung des SSO-Services: Installation eines SP -> Apache/Tomcat Konfiguration, Anpassung der Anmeldung im Programm Zertifikat des ZIV -> Wir nur verteilt, wenn Anwendung um regulären Vorlesungs-Betrieb benutzt wird Übermittelte Attribute: -> Autorisierung muss selbst übernommen werden -> eigene Benutzerdatenbank Nachname Universitäts- -Adresse ZIV-Kennung Verwendung der Benutzerdatenbank des ZIV Authentifizierung ist vom eigentlichen System entkoppelt. Freitag, 16. März 2008

20 Anmeldung bei xLx Freitag, 16. März 2008

21 Anmeldung beim IdP des ZIV
Freitag, 16. März 2008

22 Weiterleitung zurück zum SP
Freitag, 16. März 2008

23 Zugriff auf den geschützten Bereich
Freitag, 16. März 2008

24 Anmeldung bei Learnr Freitag, 16. März 2008

25 Direkte Weiterleitung zum geschützten Bereich
Freitag, 16. März 2008

26 Zugriff auf den geschützten Bereich
Freitag, 16. März 2008

27 SSO gewinnt an Bedeutung[Arr08]
Fazit SSO gewinnt an Bedeutung[Arr08] Nutzenzuwachs für Benutzer und Entwickler/Admins Universitätsübergreifendes SSO-Netz denkbar Im Rahmen des SaxIS-Projekts in Sachsen bereits eingeführt[Sax06] Probleme: Single Sign-Out Anpassungsaufwand Freitag, 16. März 2008

28 Literaturverzeichnis
[Arr08] Micheal Arrington: OpenID Welcomes Microsoft, Google, Verisign and IBM, Zuletzt abgerufen am [Ben07] Ralf Bendrath: OpenID - next big thing with lots of problems, Zuletzt abgerufen am [Dec02] J. De Clercq: Single Sign-On Architectures, in Lecture notes in computerscience vol. 2437, S. 40 – 58, Springer-Verlag, 2002. [Ebe06] Lars Eberle, SaxIS-Shibboleth-Workshop, Zuletzt abgerufen am Freitag, 16. März 2008

29 Literaturverzeichnis
[Koc07] Christian Koch: Single Sign-On – Komfort für den Benutzer oder ein Sicherheitsrisiko?, Zuletzt abgerufen am [Ope01] Introduction to Single Sign-On, Zuletzt abgerufen am [Jan04] Wilhelm Janssen: Autorisierung, Zuletzt abgerufen am [Ker07] What is Kerberos?, Zuletzt abgerufen am Freitag, 16. März 2008

30 Literaturverzeichnis
[Lau07] Ben Laurie: OpenID: Phishing Heaven, Zuletzt abgerufen am [OAS07] OASIS Security Services (SAML) TC, Zuletzt abgerufen am [Wie08] Mike Wiesner, Kerberos V5 mit Debian, Zuletzt abgerufen am Freitag, 16. März 2008

31 Fragen? Freitag, 16. März 2008

32 Implementierung Installation und Konfiguration eines SP:
Shibboleth Dienst bzw. Daemon installieren (shibd) Apache/Tomcat Konfiguration: shibboleth.xml httpd.conf: <Location /geschützte_ressource> AuthType shibboleth ShibRequireSession On ShibRedirectToSSL require valid-user </Location> AAP.xml: <AttributeRule Name="urn:mace:dir:attribute-def:mail" Header="Shib-mail"> <AnySite> <AnyValue/> </AnySite> </AttributeRule> Freitag, 16. März 2008

33 Auslesen des HTTP-Headers
Implementierung Auslesen des HTTP-Headers Code-Beispiel in Java: String = request.getHeader(“Shib-mail”); Leicht wartbar, da nur bei einer Pfadänderung die httpd.conf angepasst werden muss. Freitag, 16. März 2008