Ein technischer Überblick

Transkript

1 Wie funktioniert Shibboleth? Ein technischer Überblick 3. AAR-Workshop Freiburg, 10. Oktober 2006 Franck Borel, UB Freiburg

2 Übersicht Was ist Shibboleth? Warum Shibboleth? Wie funktioniert Shibboleth? Identity-Management und Shibboleth Autorisierung und Zugriffskontrolle Föderation Ausblick: Shibboleth 2.0 2

3 Was ist Shibboleth? Shibboleth ist ein Internet2/MACE-Projekt (MACE = Middleware Architecture Committee for Education) Shibboleth ist ein einrichtungsübergreifender SSO-Dienst für den Zugriff auf geschützte Web- Ressourcen 3

4 Warum Shibboleth? Autorisierung und Zugriffskontrolle erfolgt über Attribute mit der Möglichkeit zur anonymen/pseudonymen Nutzung von Angeboten Aufwand für Integration mit vorhandenem Identity- Management und webbasierten Anwendungen ist vergleichsweise gering weltweit hohe Akzeptanz, auch bei kommerziellen Anbietern (Elsevier, JSTOR, EBSCO, CSA, Ovid, GENIOS...) Open-Source basiert auf bewährter Software (Apache, Tomcat, OpenSSL) und Standards... 4

5 Wie funktioniert Shibboleth? Shibboleth baut auf folgende Standards auf: SSL/TSL HTTP/HTTPS XML XML Schema (XSD) XML Signatur (XMLDisg) SOAP SAML (Security Assertion Markup Language) HTTP/HTTPS SOAP Nachricht SOAP Header SOAP Body SAML Anfrage/Antwort 5

6 Wie funktioniert Shibboleth? Sicherheitsmechanismen SSL/TSL: Man-in-the-Middle, Manipulieren von Nachrichten, Lauschangriff XMLsig: Manipulieren von Nachrichten Eingeschränkte Gültigkeitsdauer von Sitzungen, Bestätigungen, Attributen (engl. Lifetime, TTL): Wiederverwendung von Sitzungsdaten, DoS Metadaten: DoS, Manipulieren von Nachrichten Es werden keine personenbezogenen Daten übermittelt, sondern Stellvertreter (engl. Handler): Lauschangriff 6

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

8 Wie funktioniert Shibboleth? Folgekontakt (gleicher Anbieter) (1) Anbieter Benutzerin bekannt? (2) ja Benutzerin Benutzerin berechtigt? (7) ja nein (9) gestattet verweigert Zugriff 8

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

10 Wie funktioniert Shibboleth? Server- Zertifikat SSL Bestandteile SSL Server- Zertifikat Heimateinrichtung Benutzer Anbieter 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 10

11 Wie funktioniert Shibboleth? Bestandteile: Technik Heimateinrichtung Apache mit SSL Authentifizierungsverfahren: (fast) beliebig Identity-Provider AA + ARP Tomcat SSO- Service Identity-Management: (fast) beliebig Benutzer WAYF Tomcat Anbieter Service Provider Web-Server Optional: Zugangskontrolle mod_shib (ACS) Zugangskontrolle: (fast) beliebig Shibd +AAP Web-Ressource: Daten, Anwendungen 11

12 Wie funktioniert Shibboleth? Wann erfolgt eine neue Anmeldung? Die Sitzung (Session) des SSO ist abgelaufen (Timeout) Der Browser wurde geschlossen Benutzer hat mehrere Identitäten und für jede Identität andere Attribute und damit andere Rechte (technische Umsetzung?) Single Log-Out (Shibboleth 2.0) Keine neue Anmeldung Sitzung des Service-Provider wurde beendet (Anwendung oder SSO-Dienst) Wechsel des Service-Provider 12

13 Identity-Management und Shibboleth Identity-Management wird benötigt für: Authentifizierung (identifiziert den Benutzer) Autorisierung (stellt die Attribute zur Verfügung) Shibboleth stellt keine besonderen Anforderungen an das Identity-Management Fertige Schnittstellen zu LDAP, SQL-Datenbanken etc. Nichtvorhandene Schnittstellen können programmiert werden Die Föderation stellt qualitative und rechtliche Anforderungen an das Identity-Management: Verlässlichkeit Aktualität Nachvollziehbarkeit Ausfallsicherheit Datenschutz 13

14 Attribute und Zugriffskontrolle 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. Service-Provider werten die Attribute anhand ihrer Regeln aus und gestatten oder verweigern je nach Ergebnis den Zugriff. Hierfür sind Absprachen zwischen Identity- und Service-Providern notwendig, die durch Verwendung eines einheitlichen Schemas vereinfacht werden! Voraussetzung sind verlässliche Benutzerdaten, also ein funktionierendes Identity-Management 14

15 Attribute und Zugriffskontrolle InCommon hat mit eduperson den Standard für den Austausch von Attributen vorgegeben. Andere Föderationen und internationale Anbieter orientieren sich an diesem Standard. Die Anbieter kommen mit wenigen Attributen aus: edupersonaffiliation: member, faculty, staff, student,... edupersonentitlement: beliebige Rechteinformationen, z.b. urn:mace:dir:entitlement:common-lib-terms edupersonprincipalname: Net-ID des Benutzers edupersontargetedid: eindeutiges Pseudonym des Benutzers für einen Anbieter, z.b. für Personalisierung 15

16 Attribute und Zugriffskontrolle Attribute können personenbezogene Daten sein (Beispiele: Benutzerkennung, adresse). Personenbezogene Daten dürfen nach den (EU-) Datenschutzbestimmungen nur weitergegeben werden, wenn dies für die Erbringung des Dienstes notwendig ist und der Benutzer der Weitergabe ausdrücklich zustimmt. Die Weitergabe der Attribute erfolgt in Shibboleth über Attribute-Richtlinien (Attribute Release Policies) auf Einrichtungs- und Benutzerebene. MAMS erweitert mit ShARPE/Autograph die Attribute- Richtlinien um die Gruppenebene. 16

17 Attribute und Zugriffskontrolle MAMS (Meta-Access Management System, Australien) hat Werkzeuge für die Verwaltung der ARPs entwickelt (siehe ShARPE (Shibboleth Attribute Release Policy Editor, Administrationsschnittstelle) und Autograph (Benutzerschnittstelle) Die Attribute, die an einen Service-Provider weitergegeben werden, werden den Benutzern in Form von Visitenkarten präsentiert. Die Benutzer können für jeden Service-Provider sehr intuitiv individuelle Visitenkarten erstellen. 17

18 Attribute und Zugriffskontrolle MAMS Visitenkartenmodell Sie geben folgende Daten an den Dienstanbieter weiter. Wenn Sie einzelne Daten nicht weitergeben wollen, löschen Sie bitte die Markierung: Namen: Franck Borel Mitgliedstyp: Staff X X Auswirkung: Ohne -Adresse ist die Nutzung des Alert-Dienstes nicht möglich. 18

19 Attribute und Zugriffskontrolle Heimateinrichtung Fordert Attribute an Anbieter Identity-Provider Attribute Authority (AA) (1) Service Provider Shibd (4) (3) ARP AAP (5) (2) (3) Filtert Attribute Zugriffskontrolle (6) Identity-Management Web-Ressource Hole alle Attribute Erhält gefilterte Attributliste und entscheidet über den Zugriff 19

20 Föderation Einrichtungen Anbieter Föderation 20

21 Föderation Eine Föderation ist ein Zusammenschluss von Einrichtungen und Anbietern auf Basis gemeinsamer Richtlinien. Eine Föderation schafft das notwendige Vertrauen zwischen Einrichtungen und Anbietern und den organisatorischen Rahmen für den Austausch von Benutzerinformationen. Unter Koordination des DFN ensteht eine deutschlandweite Föderation (DFN-AAI) 21

22 Ausblick: Shibboleth 2.0 Zeitrahmen für Shibboleth 2.0: Anfang 2007? Kompatibel mit Shibboleth 1.3 erweiterte Authentifizierungsfunktionalität Single Logout (technisch schwer umzusetzen!) Service-Provider als 2.3 Java-Servlet Attribut-Verwaltung (IdP) wird erweitert: Filterfunktion auf Gruppenebene (bisher nur Filterfunktionen auf Einrichtungs- und Benutzerebene) Dynamisches Laden der Filtereinstellungen Unterstützt ShARPE/Autograph statt WAYF: Discovery-Service mit Rückleitung zum Service-Provider 22

23 Shibboleth in Aktion DEMO 23

24 Vielen Dank für Ihre Aufmerksamkeit! AAR ist ein Projekt der UB Freiburg und UB Regensburg. Gefördert vom BMBF (PT-NMB+F ) aar.vascoda.de info@aar.vascoda.de borel@ub.uni-freiburg.de 24