Infrastruktur zur verteilten Authentifizierung und Autorisierung mit Shibboleth im Rahmen der Deutsche Föderation DFN-AAI

Transkript

1 Infrastruktur zur verteilten Authentifizierung und Autorisierung mit Shibboleth im Rahmen der Deutsche Föderation DFN-AAI Das Projekt Authentifizierung, Autorisierung und Rechteverwaltung (AAR) Ato Ruppert, UB Freiburg Erste Fachtagung für Datenschutzbeauftragte an Hochschulen und anderen wissenschaftlichen Einrichtungen / , Berlin

2 Das Projekt AAR Partner: UB Freiburg und bis UB Regensburg Seit 10/2006 auch Partner des Deutschen Forschungsnetz, DFN finanziert durch das BMBF (PT-NMB+F) und eingebettet in vascoda ( Laufzeit 01/2005 bis 06/2008: 2 Jahre Entwicklungs- und Testphase mit der Regionalen Datenbank- Information Baden-Württemberg (ReDI) und vascoda als Pilotanwendungen 1,5 Jahre Aufbau der Deutschen Föderation (mit DFN-Verein) Laufend: Unterstützung von Einrichtungen und Anbietern bei der Einführung des Systems, Workshops, Schulungen, Marketing Der DFN-Verein übernimmt das nachhaltige Dienstangebot im Jahr 2008 vollständig unter dem Namen DFN-AAI. 13./ Ato Ruppert 2

3 Gliederung Das Szenario im Informationsbereich Aktuelle Technik und Ziele Allgemeines zu Shibboleth und Single Sign-On (SSO) Datensicherheit und Datenschutz Weitergabe von Attributen Aufgaben der Föderation Einsatzmöglichkeiten, Beispiele, Fazit 13./ Ato Ruppert 3

4 13./ Ato Ruppert 4

5 13./ Ato Ruppert 5

6 13./ Ato Ruppert 6

7 13./ Ato Ruppert 7

8 13./ Ato Ruppert 8

9 13./ Ato Ruppert 9

10 Bisherige Lösung: Kontrolle Authentifizierung und Autorisierung nicht getrennt! Eine Authentifizierung findet im eigentlichen Sinn nicht statt Vorteile: Sehr einfach Sicher geringste Datenintensität! Nachteil: funktioniert zunächst nur ortsgebunden Lösungsmöglichkeiten des Ortsbindungsproblems: VPN, Proxies, Rewriting Proxies (HAN, EZProxy) Unsicherheiten: Fälschbare Adressen, Offene Proxies 13./ Ato Ruppert 10

11 Bisherige Lösung: Login/Password Authentifizierung durch Login/Password. Autorisierung ist ein getrennter Schritt. Datenintensität gering, Daten aber vielfach verteilt und vom Nutzer kaum noch kontrollierbar. Falls der Anbieter zusätzliche Daten verlangt, wird die Datenintensität höher und. Nutzer gibt zwar bewusst seine Daten weiter, hat aber keine Alternative. 13./ Ato Ruppert 11

12 Was wollen wir erreichen? Nutzer Der Zugriff auf lizenzierte Inhalte soll unabhängig vom gewählten Arbeitsplatz und dem Zugriffsweg möglich sein. Alle lizenzierten Inhalte sollten nach nur einmaliger Anmeldung zur Verfügung stehen (Single Sign-On). Möglichst keine Weitergabe von personenbezogenen Daten. Einrichtungen (etwa Hochschulen) Die Einrichtung soll ein beliebiges Authentifizierungssystem wählen dürfen und betreibt dazu ein Identity Management System (IdM) Anbieter Die lizenzpflichtigen Inhalte der Anbieter sollen vor unberechtigten Zugriff geschützt werden. 13./ Ato Ruppert 12

13 Was ist Shibboleth? Shibboleth ist ein Internet2/MACE-Projekt (MACE = Middleware Architecture Committee for Education) Shibboleth entwickelt eine Architektur (Protokolle und Profile), Richtlinien-Strukturen und eine Open Source-Implementierung für den einrichtungsübergreifenden Zugriff auf geschützte (Web-)Ressourcen Shibboleth basiert auf einem föderativen Ansatz: Die Einrichtung verwaltet und authentifiziert ihre Mitglieder und der Anbieter kontrolliert den Zugang zu seinen Ressourcen 13./ Ato Ruppert 13

14 Warum Shibboleth? Autorisierung und Zugriffskontrolle über Attribute mit der Möglichkeit zur anonymen/pseudonymen Nutzung von Angeboten basiert auf bewährter Software und Standards (SAML, XML, SOAP, TLS, XMLsig, XMLenc) Aufwand für Integration mit vorhandenem IdM und (webbasierten) Anwendungen in vielen Fällen vergleichsweise gering Weltweit hohe Akzeptanz, auch bei kommerziellen Anbietern (Elsevier, JSTOR, EBSCO, Ovid, GBI, CSA,...) 13./ Ato Ruppert 14

15 Woher kommt Shibboleth? Hintergrund ist eine Stelle aus dem Alten Testament, Buch Richter Kapitel 12 Vers 5ff: Und die Gileaditer nahmen ein die Furt des Jordans vor Ephraim. Wenn nun sprachen die Flüchtigen Ephraims: Laß mich hinübergehen, so sprachen die Männer von Gilead zu ihm: Bist du ein Ephraiter? Wenn er dann antwortete: Nein, so hießen sie ihn sprechen: Schiboleth, so sprach er: Siboleth, und konnte es nicht recht reden. So griffen sie ihn und schlugen ihn an der Furt des Jordans, daß zu der Zeit von Ephraim fielen zweiundvierzigtausend. (Zitat (vergl. auch: Das Wort Shibboleth ist somit wohl das erste biometrische Autorisierungsverfahren gewesen! Shibboleth s heute: Awwer hache derfst misch net! 13./ Ato Ruppert 15

16 Wie funktioniert Shibboleth? Benutzerin (5) Login (3) Erstkontakt (1) Lokalisierungsdienst (WAYF, IdP Discovery) (4) (6) Anbieter Benutzerin angemeldet? (2) nein Benutzerin berechtigt? Heimateinrichtung (7) (8) ja nein (9) gestattet verweigert Zugriff 13./ Ato Ruppert 16

17 Wie funktioniert Shibboleth? Folgekontakt (gleicher Anbieter) (1) Anbieter Benutzerin bekannt? (2) ja Benutzerin Benutzerin berechtigt? (7) ja nein (9) gestattet verweigert Zugriff 13./ Ato Ruppert 17

18 Wie funktioniert Shibboleth? Benutzerin Folgekontakt anderer Anbieter (1) (3) Lokalisierungsdienst (WAYF, IdP Discovery) (4) (6) Anbieter Benutzerin bekannt? (2) nein Benutzerin berechtigt? Heimateinrichtung (7) (8) ja nein (9) gestattet verweigert Zugriff 13./ Ato Ruppert 18

19 Wie funktioniert Shibboleth? Datensicherheit Server- Zertifikat SSL Heimateinrichtung Browser des Benutzer SSL Anbieter Server- Zertifikat Authentifizierungsverfahren Identity-Provider Metadaten Server- Zertifikat WAYF Metadaten Zertifikat Service-Provider Metadaten Optional: lokaler WAYF, Rechteserver Cient- Zertifikat Optional: ShARPE/Autograph Identity-Management SSL Server- Zertifikat Zugangskontrolle Web-Ressource 13./ Ato Ruppert 19

20 Attribute Personen erhalten elektronische Identität (IdM) Attribute beschreiben die Rolle der Person Attribute bilden die Grundlage für die Autorisierung und Zugriffskontrolle in Shibboleth: Identity-Provider stellen mit Attributen die notwendigen Informationen über ihre Benutzer zur Verfügung. (IdP). Service-Provider werten die Attribute anhand ihrer Regeln aus und gestatten oder verweigern je nach Ergebnis den Zugriff (SP). Hierfür sind Absprachen zwischen Identity- und Service- Providern notwendig, die durch Verwendung eines einheitlichen Attributschemas vereinfacht werden! Das Attributschema der deutschen Föderation DFN-AAI basiert auf internationalen Standards. Voraussetzung sind verlässliche Benutzerdaten, also ein funktionierendes lokales Identity-Management! 13./ Ato Ruppert 20

21 Anforderungen an IdM, die sich aus dem föderativen Verfahren ergeben Qualitätsanforderungen Verlässlichkeit: Sicherheitsstufen, Missbrauchsverhinderung Aktualität: zeitnahe Änderung Nachvollziehbarkeit: Dokumentation, Logging Ausfallsicherheit: Back-up-Systeme Einklang mit rechtlichen Vorgaben Datenschutzgesetz, vor allem: Datensparsamkeit 13./ Ato Ruppert 21

22 Fragen bei der Nutzung des IdM zur Authentifizierung und Autorisierung Zulässigkeit (wozu wurden Daten erhoben?) Zweckändernde Verarbeitung ( 14 BDSG) liegt vor, daher: BDSG 14 Abs. 2 Nr. 2 der Betroffene eingewilligt hat oder: BDSG 14 Abs. 2 Nr. 3: keine Zustimmung nötig, offensichtlich ist, daß es im Interesse des Betroffenen liegt, und kein Grund zu der Annahme besteht, daß er in Kenntnis des anderen Zwecks seine Einwilligung verweigern würde 13./ Ato Ruppert 22

23 Weitergabe: 16 Abs.1 Nr.2 Weitergabe von Daten ( 15, 16 BDSG) 16 Datenübermittlung an nichtöffentliche Stellen (1) Die Übermittlung personenbezogener Daten an nichtöffentliche Stellen ist zulässig, wenn 2. der Dritte, an den die Daten übermittelt werden, ein berechtigtes Interesse an der Kenntnis der zu übermittelnden Daten glaubhaft darlegt und der Betroffene kein schutzwürdiges Interesse an dem Ausschluss der Übermittlung hat. 13./ Ato Ruppert 23

24 edupersonentitlement: Beispiele urn:mace:dir:entitlement:common-lib-terms Benutzer ist berechtigt, die von der Einrichtung lizenzierten Ressourcen zu nutzen (NUR Standardverträge) urn:mace:ebsco.com:entitlement:<ebsco-account> Benutzer darf die auf dem <EBSCO-Account> der Einrichtung verfügbaren Ressourcen nutzen urn:mace:ub.uni-freiburg.de:entitlement:unist:redi:admin Benutzer der Universität Stuttgart mit Administratorrechten in ReDI In jeden Fall: Absprachen zwischen IdP und SP notwendig! 13./ Ato Ruppert 24

25 edupersonscopedaffiliation Ermöglicht die Zuordnung der Benutzer einer Einrichtung zu einigen grundlegenden Rollen Zulässige Werte: member, faculty, staff, employee, student, alum und affiliate Beispiel: Erste Implementierungen von kommerziellen Anbietern (EBSCO) basierten auf diesem Attribut. Probleme: Semantik ist auf internationaler Ebene nicht wirklich einheitlich festgelegt (Was genau ist z.b. ein student?) Es fehlen wichtige Rollen wie walk-in patron, on campus. 13./ Ato Ruppert 25

26 edupersontargetedid Eindeutiges, persistentes Pseudonym des Benutzers für einen Service-Provider Ermöglicht die Wiedererkennung des Benutzers (z.b. bei personalisierten Anwendungen), ohne die Identität des Benutzers zu kennen Erschwert das Zusammenführen von Informationen über einen Benutzer seitens der Service-Provider Beispiel: Ruppert,EBSCO wird durch MD5 zu: be83f47a1e56631eceddde08e8a76fa3 13./ Ato Ruppert 26

27 edupersonprincipalname Eindeutiger, persistenter Identifier des Benutzers inklusive Domain ("NetID") Beispiel: Sollte aus Datenschutzgründen nur verwendet werden, wenn die Nutzung des Dienstes nicht anonym oder pseudonym erfolgen kann! Anwendungsbeispiel: Schreibender Zugriff auf eine Anwendung (z.b. Wiki, Forum oder Repositorium ), bei der der Autor sich zu erkennen geben muss. Weitergabe NUR unter Beachtung des Datenschutzgesetzes! 13./ Ato Ruppert 27

28 Weitergabe von Attributen: Das Modell ShARPE Autograph (MAMS) Die Attribute, die an einen Service-Provider weitergegeben werden, werden den Benutzern in Form von Visitenkarten präsentiert. Benutzer können für jeden Service-Provider individuelle Visitenkarten erstellen. Die Bedienung ist sehr intuitiv: Streichen von Attributen schränkt die verfügbaren Dienste entsprechend ein Auswahl eines gewünschten Dienstes fügt automatisch die notwendigen Attribute hinzu 13./ Ato Ruppert 28

29 Visitenkartenmodell von MAMS Sie geben folgende Daten an den Dienstanbieter weiter. Wenn Sie einzelne Daten nicht weitergeben wollen, löschen Sie bitte die Markierung: Namen: Ruppert Mitgliedstyp: Staff Mail: X X X Auswirkung: Ohne Mail-Adresse ist Nutzung des Alert-Dienstes nicht möglich. 13./ Ato Ruppert 29

30 SWITCH Das Modell von Switch ArpViewer 13./ Ato Ruppert 30

31 Die Föderation DFN-AAI Wo ist das Problem? Anbieter muss dem Anwender vertrauen. Es geht um Geld. Vertrauen heißt im Geschäftsleben: Vertrag. Es müssen belastbare vertragliche Regelungen getroffen werden. Es müssen Regeln für den technischen Betrieb existieren. DFN-AAI ist ein Dienst des DFN-Vereins für Wissenschaftseinrichtungen und (auch für kommerzielle) Anbieter von (Informations)-Ressourcen. DFN-AAI schafft das für notwendige Vertrauensverhältnis und einen organisatorischen, technischen Rahmen für den Austausch von Nutzerinformationen zwischen vielen Anwendern und vielen Anbietern. 13./ Ato Ruppert 31

32 Aufgaben der DFN-AAI Vorgabe von Richtlinien (Policy) Vertragsgestaltung und -abschluss Public Relations & internationale Vertretung zentrale betriebliche Aufgaben Metadatenverwaltung der teilnehmenden Einrichtungen WAYF-Server (Discovery-Service) Testsystem für neue Teilnehmer und neue Software Web-Portal mit Informationen Schulung, Beratung übernimmt nicht die Lizenzverträge. 13./ Ato Ruppert 32

33 Einsatzmöglichkeiten von SSO Zugang zu geschützten (auch und gerade kommerziellen) elektronischen Informationsangeboten: E-Zeitschriften, Datenbanken, E-Bücher,... Portale (z.b. vascoda, ReDI) DFG-Nationallizenzen Repositories e-learning e-science Verwaltungssysteme Grid-Computing 13./ Ato Ruppert 33

34 Beispiel: Nationallizenzen: Die Situation heute institutionelle Nutzer Zugangsvermittlung mit proprietären Verfahren z.b. ReDI Verlag-1 Kontrolle Einrichtung-1 Verlag-2 Kontrolle Kontrolle Einrichtung-2 Verlag-m Kontrolle 13./ Ato Ruppert 34

35 Beispiel: Nationallizenzen: Die Situation heute institutionelle Nutzer Einrichtung-2 z.b. ReDI Zugangsvermittlung mit proprietären Verfahren Einige Zahlen: Der GBV verwaltet für die Nationallizenzen: Kontrolle - über Adressen von Einrichtung-1 - über 360 Einrichtungen Verlag-2 - für mehr als 100 Anbieter - mehr als 60 Mill. Nachweisdaten in unterschiedlichen Sammlungen Verlag-1 Verlag-m Kontrolle Kontrolle Kontrolle 13./ Ato Ruppert 35

36 Nationallizenzen und das Ziel mit Shibboleth 1x 1x NL VHO Shib idp Shib sp Verlag-1 Shib sp ReWriting Proxy IP IP Ggf mehrere Instanzen (Einrichtungen) Ctrl Verlag-2 Shib idp IP IP Shib sp Falls Einrichtung über IP authentifiziert Verlag-m 13./ Ato Ruppert 36

37 Das Projekt mylogin der Uni Freiburg E-Learning Personalisierte Dienste Seminararbeit IdM Bibliotheksdienste Verwaltungssysteme 13./ Ato Ruppert 37

38 Das Projekt mylogin der Uni Freiburg E-Learning Personalisierte Dienste Single-SignOn mit Shibboleth, ein Login für alle Dienste Seminararbeit Bibliotheksdienste Verwaltungssysteme 13./ Ato Ruppert 38

39 Chance und Vision: Authentifizierung & Personalisierung Meine Bibliothek Logout Meine Einstellungen Katalogauswahl: Mein Katalog Meine Dienste: Mein OLAF-Konto: Mein Fachportal 5 1 4,50 Eur derzeit keine derzeit keine E-Learning 13./ Ato Ruppert 39

40 Fazit oder wem nützt was? Die Nutzer haben deutlich vereinfachte Verfahren beim Zugang zu lizenzierten Diensten Die Daten der Nutzer liegen nur noch an einer Stelle (bei der Heimateinrichtung ) Sichere Übertragungswege mit einem weltweit einheitlichen Verfahren Die vertrauenswürdige Infrastruktur der Föderation unterstützt auch die Bedürfnisse der Anbieter Einheitliche Authentifizierung und Autorisierung innerhalb einer Einrichtung Kein direkter Zugang zum Authentifizierungssystem für alle Administratoren, daher besserer Schutz. 13./ Ato Ruppert 40

41 Vielen Dank für Ihre Aufmerksamkeit! AAR ist ein Projekt der UB Freiburg. Gefördert vom BMBF (PT-NMB+F ) AAR kooperiert mit dem DFN-Verein aar.vascoda.de info@aar.vascoda.de ruppert@ub.uni-freiburg.de 13./ Ato Ruppert 41