330 likes | 447 Views
Einsatz von Single-Sign-On Technologien im Rahmen der Integration von E-Learning Anwendungen. Christian Nockemann. Agenda. 1. Einleitung 2. Single Sign-On 3. SSO im E-Learning Kontext 4. Live Demo 5. Fazit. Einleitung. Unüberschaubare Anzahl von Web-Ressourcen
E N D
Einsatz von Single-Sign-On Technologien im Rahmen der Integration von E-Learning Anwendungen Christian Nockemann
Agenda 1. Einleitung 2. Single Sign-On 3. SSO im E-Learning Kontext 4. Live Demo 5. Fazit
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
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
Autorisierung und Single Sign-Out • Autorisierung: • 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
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
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
OpenID • Sehr populär [Arr08] • Beschränkt sich auf grundlegende SSO-Funktionen • Vier Parteien: • Client • OpenID Server • Identity Server • Consumer
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
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
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
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 • Aufwändige Anpassung, kein Single Sign-Out → Kerberos und Shibboleth sind für das E- Learning Umfeld am besten geeignet
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
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
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
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
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.
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.
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.
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>
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.