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

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

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

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

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

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

Authentifizierungsprotokoll Starke Kryptographie [Ker07] Kerberos Authentifizierungsprotokoll Starke Kryptographie [Ker07] Authentifizierung mit so genannten Tickets Drei Parteien [Wie08]: Principal (z.B. c_nock01/student@uni-muenster) 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. c_nock01/student@uni-muenster) -> komponente1/komponente2@realm -> 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

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

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

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

Anmeldung mit OpenID Freitag, 16. März 2008

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

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

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

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

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

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

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

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-Email-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-Email-Adresse ZIV-Kennung Verwendung der Benutzerdatenbank des ZIV Authentifizierung ist vom eigentlichen System entkoppelt. Freitag, 16. März 2008

Anmeldung bei xLx Freitag, 16. März 2008

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

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

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

Anmeldung bei Learnr Freitag, 16. März 2008

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

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

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

Literaturverzeichnis [Arr08] Micheal Arrington: OpenID Welcomes Microsoft, Google, Verisign and IBM, http://www.techcrunch.com/2008/02/07/openid-welcomes-microsoft-google-verisign-and-ibm/. Zuletzt abgerufen am 09.04.08. [Ben07] Ralf Bendrath: OpenID - next big thing with lots of problems, http://bendrath.blogspot.com/2007/04/openid-next-big-thing-with-lots-of.html. Zuletzt abgerufen am 20.04.08. [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, http://www.tu-freiberg.de/~saxis/content/dokumente/Eberle_TU_Freiberg.pdf?PHPSESSID=c07726a2852cb0ed7a5122f2562edc8e. Zuletzt abgerufen am 08.04.08. Freitag, 16. März 2008

Literaturverzeichnis [Koc07] Christian Koch: Single Sign-On – Komfort für den Benutzer oder ein Sicherheitsrisiko?, http://www.securitymanager.de/magazin/artikel_996_single_sign_on_komfort_fuer_den_benutzer_oder.html. Zuletzt abgerufen am 01.04.08. [Ope01] Introduction to Single Sign-On, http://www.opengroup.org/security/sso_intro.htm. Zuletzt abgerufen am 04.04.08. [Jan04] Wilhelm Janssen: Autorisierung, http://www.at-mix.de/autorisierung.htm. Zuletzt abgerufen am 19.04.08. [Ker07] What is Kerberos?, http://web.mit.edu/kerberos/www/#what_is. Zuletzt abgerufen am 08.04.08. Freitag, 16. März 2008

Literaturverzeichnis [Lau07] Ben Laurie: OpenID: Phishing Heaven, http://www.links.org/?p=187. Zuletzt abgerufen am 20.04.08. [OAS07] OASIS Security Services (SAML) TC, http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security. Zuletzt abgerufen am 04.04.08. [Wie08] Mike Wiesner, Kerberos V5 mit Debian, http://meetings-archive.debian.net/pub/debian-meetings/2005/linuxtag-karlsruhe/debianday/mike_wiesner-kerberos_v5_mit_debian.pdf. Zuletzt abgerufen am 08.04.08. Freitag, 16. März 2008

Fragen? Freitag, 16. März 2008

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 443 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

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