1 / 33

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

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

kirima
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Agenda 1. Einleitung 2. Single Sign-On 3. SSO im E-Learning Kontext 4. Live Demo 5. Fazit

  3. 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

  4. 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

  5. Token-basierte Weiterleitung [Dec02]

  6. 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

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

  8. Anmeldung mit Kerberos

  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

  10. OpenID • Sehr populär [Arr08] • Beschränkt sich auf grundlegende SSO-Funktionen • Vier Parteien: • Client • OpenID Server • Identity Server • Consumer

  11. Anmeldung mit OpenID

  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

  13. 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

  14. Anmeldung mit Shibboleth

  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

  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 • Aufwändige Anpassung, kein Single Sign-Out → Kerberos und Shibboleth sind für das E- Learning Umfeld am besten geeignet

  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

  18. 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

  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-Email-Adresse • ZIV-Kennung • Verwendung der Benutzerdatenbank des ZIV

  20. Anmeldung bei xLx

  21. Anmeldung beim IdP des ZIV

  22. Weiterleitung zurück zum SP

  23. Zugriff auf den geschützten Bereich

  24. Anmeldung bei Learnr

  25. Direkte Weiterleitung zum geschützten Bereich

  26. Zugriff auf den geschützten Bereich

  27. 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

  28. 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.

  29. 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.

  30. 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.

  31. Fragen?

  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 443 require valid-user</Location> • AAP.xml:<AttributeRule Name="urn:mace:dir:attribute-def:mail" Header="Shib-mail"> <AnySite> <AnyValue/> </AnySite> </AttributeRule>

  33. 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.

More Related