Shibboleth: Grundlagen

Transkript

1 Shibboleth: Grundlagen LANIT Shibboleth Workshop Göttingen, Peter Gietz, CEO DAASI International GmbH

2 Agenda Einführung in Föderationen Einführung in Shibboleth Die niedersächsische Föderation Nds-AAI 0-2 März 2009 (c) DAASI International GmbH

3 Einführung in Föderationen 0-3 März 2009 (c) DAASI International GmbH

4 Motivation einer Hochschul-Föderation Im Rahmen des Bologna-Prozesses werden auch in Deutschland die Studiengänge verschiedener Hochschulen kompatibler Die Mobilität der Studierenden erhöht sich Studierende wollen immer öfter auch auf geschützte Ressourcen von Hochschulen, an denen sie nicht immatrikuliert sind, zugreifen Auch die Forschung ist zunehmend vernetzt und Ressourcen werden miteinander geteilt Bibliotheken handeln organisationsübergreifend Lizenzen mit Verlagen aus Ohne Föderationen ist manches hiervon gar nicht möglich, oder nur durch Externer-Accounts in den Benutzerverwaltungen 0-4 März 2009 (c) DAASI International GmbH

5 Was ist eine Föderation Eine Föderation ist ein Zusammenschluss von Organisationen zu einem bestimmten Zweck ist ein Vertrauensbund, der es ermöglicht, verteilte Ressourcen gemeinsam zu nutzen Vertrauen wird durch Verträge gewährleistet Einhaltung von Sicherheitspolicies wird versprochen ist ein System von miteinander gekoppelten Softwarekomponenten implementiert Federated Identity Management 0-5 März 2009 (c) DAASI International GmbH

6 Identity Management Definition von Spencer C. Lee: Identity Management bezieht sich auf den Prozess der Implementierung neuer Technologien zum Verwalten von Informationen über die Identität von Nutzern und zur Kontrolle des Zugriffs auf Firmenressourcen. Das Ziel von Identity Management ist es, Produktivität und Sicherheit zu erhöhen und gleichzeitig Kosten der Verwaltung von Benutzern, ihrer Identitäten, Attribute und Berechtigungsnachweise zu senken 0-6 März 2009 (c) DAASI International GmbH

7 Federated Identity Management FIdM ist Identity Management, welches über die Grenzen einer Organisation hinweg Identitätsinformationen zur Verfügung stellt und im Rahmen von Föderationen zum Zwecke der Authentifizierung und Autorisierung nutzt. Hierbei werden die lokalen IdM-Systeme bzw. Authentifizierungsdienste genutzt, sodass nicht jeder Benutzer in jeder Organisation einen Account benötigt Voraussetzung ist ein Vertrauensbund zwischen den Organisationen, der über Verträge hergestellt wird Es kommen hierbei moderne Standards zum Einsatz, insbesondere SAML (Security Assertion Markup Language) Technologien sind z.b.: Liberty Alliance, Shibboleth, WS- Security 0-7 März 2009 (c) DAASI International GmbH

8 Grundbausteine einer Föderation Eine Föderation besteht aus drei Bausteinen: Föderationsverwaltung zentraler Vertragspartner für Föderationsmitglieder Verwaltet Zugangsdaten zu den einzelnen Bausteinen ( Metadaten ) betreibt zentrale Infrastrukturkomponenten Identity Provider (IdP) Benutzerverwaltung der Heimatorganisation verantwortlich für Authentifizierung und Attribute Service Provider (SP) Verantwortlich für Ressourcen Entscheidet aufgrund von Aussagen des IdP 0-8 März 2009 (c) DAASI International GmbH

9 Voraussetzungen für eine Föderation 1 Verwaltung der Föderationsmitgliedschaft Liste der Mitgliedsorganisationen Verträge zwischen den Mitgliedern (n to n, oder 1 to n) Sicherer Datenaustausch zwischen Mitglied und Föderationsverwaltung, z.b. durch X.509-Zertifikate von Zertifizierungsstellen, denen alle Mitglieder vertrauen Sicherer Registrierungsmechanismus Verwaltung von Metadaten (Daten über die IdPs und SPs) Spezifizierung eines Metadatenformats Mechanismus zur sicheren Übertragung und Verwaltung von Metadaten Gewährleistung der Richtigkeit der Metadaten Sicherer Mechanismus zur Veröffentlichung der Metadaten innerhalb der Föderation 0-9 März 2009 (c) DAASI International GmbH

10 Voraussetzungen für eine Föderation 2 Mechanismus zum Auffinden der Benutzerverwaltungen Der SP muss wissen, woher der Benutzer kommt Dieser Dienst muss hochverfügbar sein Ein Benutzer kann Mitglied in mehreren Föderationen sein! Betrieb des Dienstes Betrieb der Metadatenverwaltung und des zentralen Dienstes zum Auffinden der IdPs Weiterentwicklung der Standards und Technologien beobachten Software-Updates ohne dass der Dienst unterbrochen ist 0-10 März 2009 (c) DAASI International GmbH

11 Voraussetzungen für einen IdP Zugehörigkeit zur Community Aktualität und Vollständigkeit der Benutzerdaten am besten mittels eines IdM-Systems Unterstützung des Attributschemas mindestens durch ein Mapping Unterstützung eines sicheren Authentifizierungsmechanismus (Passwörter nur über verschlüsselte Verbindungen) Implementierung der geforderten Föderationssoftware Registrierung bei der Föderation und Lieferung der Metadaten Erhebung und Speicherung von Logdaten Reaktion bei Betrugsfällen, etc. z.b. Recherchieren der Identität, die zu einer bestimmten TargetedID gehört Einhaltung des Datenschutzes 0-11 März 2009 (c) DAASI International GmbH

12 Voraussetzungen für Service Provider Zugehörigkeit zur Community Implementierung der geforderten Föderationssoftware Registrierung bei der Föderation und Lieferung der Metadaten Muss die Föderationsrichtlinien, insbesondere bezüglich des Datenschutzes befolgen Muss die Dienste zur Verfügung stellen und Zugriffskontrolle aufgrund der vereinbarten Regeln und Attribute ausüben Einhaltung des Datenschutzes 0-12 März 2009 (c) DAASI International GmbH

13 0-13 März 2009 (c) DAASI International GmbH Einführung in Shibboleth

14 Shibboleth Föderationssoftware vom US-amerkanischen Internet2- Konsortium Basiert wie Liberty Alliance auf SAML Open Source Software Version 1.3. (SAML 1.1) previous stable, unterstützt bis 06/2010 Version 2.1 (SAML 2.0) current stable viele Anwendungen werden shibbolethisiert zusätzlich eine Single Sign On-Lösung nach einmaliger Authentifizierung hat der Nutzer für eine bestimmte Zeit föderationsweit Zugriff auf verschiedene Anwendungen 0-14 März 2009 (c) DAASI International GmbH

15 SAML SAML (Security Assertion Markup Language) (OASIS) XML-Dokumente enthalten Zusicherungen (Assertions) die ein IdP über Benutzer macht: Authentication Statements, Zusicherung, dass sich ein Benutzer Authentifiziert hat Authorization Decision Statement, Zusicherung über bestimmte Zugriffsrechte Attribute Statement, Zusicherung über bestimmte Eigenschaften eines Benutzers, die in Form von Attributen weitergegeben werden und dem SP bei der Entscheidung über Zugriff unterstützen Profile spezifizieren welche Assertions wie zwischen IdP und SP ausgetauscht werden 0-15 März 2009 (c) DAASI International GmbH

16 SAML2: Profile SSO Profiles Web Browser SSO Identity Provider Discovery Single Logout (aktuell nur vom SP unterstützt) Name Identifier Management: Änderung des Werts / Formats eines Benutzers Artifact Resolution: Übergabe von Assertions per Referenz Assertion Query/Request: vhd. Assertions per Referenz abfragen oder nach Subject oder Statement type Name Identifier Mapping: IdP erlaubt Austausch über selben Principal von SP zu SP SAML Attribute Profiles: für Attributnamen und -syntax, z.b. LDAP, UUID, XACML März 2009 (c) DAASI International GmbH

17 Bausteine von Shibboleth Shibboleth baut im Wesentlichen auf zwei miteinander kommunizierende Module auf: Identity Provider (IdP), der an die lokalen Benutzerverwaltungen angeschlossen wird Kann sowohl auf einen LDAP-Server als auch auf eine SQL-Datenbank aufsetzen Service Provider (SP), der vor zu schützende Ressourcen bzw. Dienste gestellt wird Zusätzlich gibt es eine zentrale Komponente: Where Are You From Server (WAYF, Shib 1.3) bzw. Discovery Service (DS, Shib 2.x) 0-17 März 2009 (c) DAASI International GmbH

18 Shibboleth-Architektur (v1.3) Switch-AAI 0-18 Sept. März (c) DAASI International GmbH

19 Shibboleth-Architektur (v2.0) Switch-AAI 0-19 Sept. März (c) DAASI International GmbH GmbH

20 Shib1.3 vs. Shib2 Shib1.3: WAYF leitet den Benutzer gleich direkt zum IdP Nach Authentifizierung schickt IdP ein Handle über den Browser zum SP SP verwendet das Handle, um direkt beim IdP Attribute anzufordern (Back-Channel AA <-> ACS) Shib2: DS sendet Information über gewählten IdP zunächst zum SP, der diese zwischenspeichert IdP schickt nach Authentifizierung sowohl AuthN- als auch Attribute Assertion zum SP (Push) sämtliche Kommunikation erfolgt über den Browser Shib2 unterstützt sämtliche Protokolle von Shib1.3, IdP/SP kann sowohl Shib1.3er als auch Shib2er SPs/IdPs ansprechen 0-20 März 2009 (c) DAASI International GmbH

21 Die niedersächsische Föderation Nds-AAI 0-21 März 2009 (c) DAASI International GmbH

22 Nds-AAI: Wer macht was Das Projekt Nds-AAI ist eine Initiative von LANIT (Landesarbeitskreis Niedersachsen für Informationstechnik der Hochschulrechenzentren) Finanziert vom Niedersächsisches Ministerium für Wissenschaft und Kultur Implementierrung im Wesentlichen durch die DAASI International GmbH unter Mitarbeit der einzelnen Hochschulrechenzentren 0-22 März 2009 (c) DAASI International GmbH

23 Motivation für Nds-AAI Das Projekt Nds-AAI baut eine landesweite Föderation auf, die es auf Grundlage einer technischen Infrastruktur ermöglicht, den lokal in ihren Heimatorganisationen verwalteten Benutzern Ressourcen der gesamten Föderation kontrolliert zur Verfügung zu stellen. Diese Infrastruktur soll insbesondere Studierenden ermöglichen, Lerninhalte von E-Learning-Plattformen der verschiedenen Hochschulen zu nutzen, ohne in all diesen Hochschule einen Benutzeraccount haben zu müssen. Die erste Anwendung, die über die Nds-AAI zugänglich gemacht wurde, ist die E-Learning-Software StudIP März 2009 (c) DAASI International GmbH

24 Warum nicht gleich DFN-AAI? Festdefinierter Kreis der Mitglieder: Hochschulen in Niedersachsen Nds-AAI ist zunächst für einen bestimmten Zweck gedacht: elearning mit StudIP Es gibt bereits elearning-kooperationen in Niedersachsen Anforderungen an die Benutzerverwaltungen können flexibel den Einsatzszenarien angepasst werden Im Projekt können die Hochschulen gemeinsam Voraussetzungen für die Teilnahme an der DFN-AAI erarbeiten Sie können aber zu unterschiedlichen Zeitpunkten der DFN-AAI beitreten Hochschulen können mit demselben IdP an verschiedenen Föderationen teilnehmen 0-24 März 2009 (c) DAASI International GmbH

25 0-25 Sept. März (c) DAASI International GmbH Nds-AAI Architektur

26 Projektverlauf Phase I: Planung Ist-Analyse an 18 Hochschulen Spezifikation der Anforderungen Spezifikation einer Plattform (Hardware/Software) Implementierungsplan Erstellung eines Feinkonzepts Sicherheitsanalyse zum Feinkonzept 0-26 März 2009 (c) DAASI International GmbH

27 Projektverlauf Phase II: Aufbau und Test eines Prototypen Aufbau Prototyp Spezifikation von Testszenarien und deren Implementierung Installation von Shibboleth 2.0 IdP und SP auf drei Rechnern, Installation eines WAYF-Servers auf einem der drei Rechner Implementierung der Shibbolisierung von StudIP Konfiguration und Dokumentation der Konfiguration Gesamtdokumentation Prototyp Test Prototyp 0-27 März 2009 (c) DAASI International GmbH

28 Projektverlauf Phase III: Implementierung und Pilot Implementierung Installation und Test des getesteten Prototyps auf 18 Rechnern Implementierungsbericht Anschluss an die lokalen Infrastrukturen 0-28 März 2009 (c) DAASI International GmbH

29 Projektverlauf Phasenbegleitende Maßnahmen Schulungs- und Marketingmaßnahmen Durchführung eines Workshops zur Einführung in Shibboleth, Diskussion der individuellen Voraussetzungen an den einzelnen Hochschulen und Projektvorstellung Durchführung eines Workshops zum Betrieb der Infrastruktur Vorträge zum Nds-AAI-Projekts in einschlägigen Arbeitskreisen, insbesondere im ZKI-AK Verzeichnisdienste 0-29 März 2009 (c) DAASI International GmbH

30 Status Für alle Hochschulen Niedersachsen wurde ein Server bereitgestellt, auf dem Shibboleth installiert wurde Zentrale Komponenten implementiert und produktiv Nicht alle Hochschulen erfüllen die Voraussetzungen für einen Produktivbetrieb, z.b. Keine adäquate Benutzerverwaltung Kein Stud.IP Letzte juristische Abklärungen zum Datenschutz finden gegenwärtig statt Abgesehen von diesen Abhängigkeiten wurden sämtliche Merkmale eines Produktivbetriebs an allen beteiligten Hochschulen umgesetzt März 2009 (c) DAASI International GmbH

31 Datenschutz Der Benutzer muss spezifizieren können, ob und welche seiner personenbezogenen Daten vom IdP der Heimatorganisation innerhalb der Föderation weitergegeben werden. Es versteht sich von selbst, dass ein Benutzer, der die Weitergabe jeglicher Daten verbietet, keine oder nur wenige Föderationsdienste in Anspruch nehmen kann. Hierzu wurde die Software ARPViewer implementiert, womit der Benutzer je SP seine Zustimmung zur Übertragung seiner Daten geben bzw. verweigern kann März 2009 (c) DAASI International GmbH

32 ARPViewer Attribute Release Policy Viewer Von SWITCH entwickelter Filter für den IdP Die Lösung für die datenschutzrechtlichen Bedenken Ermöglicht es dem Benutzer einmalig die Zustimmung zu den Nutzungsbedingungen zu geben so oft der Benutzer möchte, die Zustimmung zur Weitergabe der personenbezogenen Daten an jeweils einen SP zu geben bzw. verweigern Interface kann beliebig grafisch gestaltet werden Diese Gestaltung ist gegenwärtig in Arbeit Die folgende Screenshots zeigen nur das Prinzip 0-32 März 2009 (c) DAASI International GmbH

33 WAYF 0-33 März 2009 (c) DAASI International GmbH

34 Login 0-34 März 2009 (c) DAASI International GmbH

35 ArpViewer: Terms of Use 0-35 März 2009 (c) DAASI International GmbH

36 ArpViewer: Attributfreigabe 0-36 März 2009 (c) DAASI International GmbH

37 Vielen Dank für Ihre Aufmerksamkeit! Kontakt und weitere Informationen: DAASI International GmbH Europaplatz 3 D Tübingen Web: Mail: info@daasi.de Bei späteren Fragen: Mail: peter.gietz@daasi.de 0-37 März 2009 (c) DAASI International GmbH

38 eduperson Wird weltweit zu einem defacto-standard für Hochschulen, der durch nationale Schemata ergänzt wird Attributtypen z.t. USA-lastig spezifiziert Kontrolliertes Vokabular für eduperson(primary)affiliation: faculty, student, staff, alum, member, affiliate, employee Vorschlag Uni-Potsdam: guest edupersonprincipalname ist als Identitäts-Token gedacht: The "NetID" of the person for the purposes of inter-institutional authentication edupersonentitlement zur Abbildung von Rechten: URI (either URN or URL) that indicates a set of rights to specific resources eduperson(primary)orgunitdn zur Abbildung der Organisationszugehörigkeit bei einem flachen Personenbaum edupersonorgdn für organisationsübergreifende Verzeichnisse 0-38 März 2009 (c) DAASI International GmbH