1 / 74

Eine föderierte AA-Infrastruktur erleichtert die Integration von Internet Diensten

Eine föderierte AA-Infrastruktur erleichtert die Integration von Internet Diensten. Berlin 29. Mai 2006. Thomas Lenggenhager SWITCH, Zürich. Ato Ruppert UB Freiburg. Ü bersicht. Motivation AAI Der Lösungsansatz Shibboleth Die Projekte SWITCHaai und AAR (DFN-AAI) Die Föderation

cana
Download Presentation

Eine föderierte AA-Infrastruktur erleichtert die Integration von Internet Diensten

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. Eine föderierte AA-Infrastrukturerleichtert dieIntegration von Internet Diensten Berlin 29. Mai 2006 Thomas Lenggenhager SWITCH, Zürich Ato Ruppert UB Freiburg 1

  2. Übersicht • Motivation AAI • Der Lösungsansatz Shibboleth • Die Projekte SWITCHaai und AAR (DFN-AAI) • Die Föderation • Rechtliche und organisatorische Rahmenbedingungen • Schritte zur Umsetzung 2

  3. Single Sign-On im Wiki • Vorteile • Zeitersparnis, da nur noch eine einzige Authentifizierung notwendig ist, um auf alle Systeme zugreifen zu können • Sicherheitsgewinn, da sich Benutzer nur noch ein Passwort merken müssen und nicht mehrere, die sie sich nicht merken können. • Sicherheitsgewinn, da das Passwort nur einmal übertragen werden muss • Nachteile • Kann ein Angreifer die Identität eines Benutzers entwenden, so stehen ihm sofort alle Systeme, auf die dieser Benutzer Zugriff hat, zur Verfügung. Daher ist es sinnvoll, eine Form der biometrischen Authentifizierung zu verwenden, um potenziellen Angreifern das Eindringen zu erschweren. 3

  4. SSO in deutschen Hochschulen und Forschungseinrichtungen? • Innerhalb von einzelnen Einrichtungen im Aufbau • Einrichtungsübergreifend sind (mir) nur wenige Dienste bekannt. (SaxIS/Bildungsportal Sachsen, ReDI/BW) • Vielerorts als „Vision“ erwähnt • Die Voraussetzungen werden derzeit (fast) überall geschaffen: IdentityManagement-Systeme 4

  5. Swiss Virtual Campus als AAI Motivator • Ziel des Swiss Virtual Campus • E-Learning an Universitäten fördern • Kurse mit hoher Qualität entsprechend jenender besten Institutionen auf ihrem Gebiet. • 2000 – 2003 Impulsprogramm • ≥ 3 teilnehmende Hochschulen pro Projekt • 50 Projekte • ~ 40 Mio CHF (24 Mio EUR) •  Bedarf für koordinierte Authentisierung der Benutzer • 2004 – 2007 Konsolidierungsprogramm •  http://virtualcampus.ch

  6. Wissenschaftportale zur Vermittlung von Informationen Das Beispiel vascoda • vascoda ist ein interdisziplinäres Internetportal für wissenschaftliche Information in Deutschland. • vascoda vereinigt Internetdienste zahlreicher leistungsstarker wissenschaftlicher Bibliotheken und Informationseinrichtungen. • Mit vascoda wird der Grundbaustein für eine "Digitale Bibliothek Deutschland" gelegt. • An vascoda sind heute über 40 Einrichtungen mit fast 30 Angeboten beteiligt. www.vascoda.de 6

  7. 7

  8. 8

  9. 9

  10. 10

  11. 11

  12. 12

  13. Was wollen wir erreichen? Leitsätze zur Nutzung verteilter Informationen im Internet aus Sicht der Nutzer, Einrichtungen und Anbieter • 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 Authentifizierung und Autorisierung (Single Sign-On) zur Verfügung stehen. • Einrichtungen (etwa Hochschulen): Die Einrichtung soll ein beliebiges Authentifizierungssystem wählen dürfen. Der Aufwand der Rechteverwaltung soll möglichst gering sein. • Anbieter:Die lizenzpflichtigen Inhalte der Anbieter sollen vor unberechtigten Zugriff geschützt werden. 13

  14. Übersicht • Motivation AAI • Der Lösungsansatz Shibboleth • Die Projekte SWITCHaai und AAR (DFN-AAI) • Die Föderation • Rechtliche und organisatorische Rahmenbedingungen • Schritte zur Umsetzung 14

  15. Universität A Stud. Admin. Web Mail e-Learning Bibliothek B e-Zeitschriften Literatur DB Universität C Research DB e-Learning Benutzerverwaltung Authentifizierung Autorisierung Ressource Passwort Ohne Shibboleth • Aufwändige Registrierung bei allen Ressourcen • Unzuverlässige und veraltete Daten • VerschiedeneLogin-Verfahren • Viele Passworte • Viele Ressourcen werden nicht geschützt • Wenn geschützt, dann oft nur durch IP-Adressen

  16. Universität A Shibboleth Stud. Admin. Web Mail e-Learning Bibliothek B e-Zeitschriften Literatur DB Universität C Research DB e-Learning Benutzerverwaltung Authentifizierung Autorisierung Ressource Passwort Mit Shibboleth • Registrierung bei denRessourcen entfällt • EinheitlichesLogin-Verfahren • Single-Sign-On • Erschliesst Benutzernneue Ressourcen • Standort-unabhängig

  17. Shibboleth • Federated Identity ManagementArchitektur und Implementation • Open Source Lizenz • Basiert auf SAML:Security Assertion Markup Language • Wird durch Internet2 entwickelt • http://shibboleth.internet2.edu

  18. 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. Das Wort „Shibboleth“ ist somit wohl das erste biometrische Autorisierungsverfahren gewesen (Zitat http://www.spiritproject.de/orakel/magie/lyrik/bibel/richter.htm) 18

  19. Wie funktioniert Shibboleth?(Erstkontakt) (1) authentifiziert? (2) (3) nein Lokalisierungsdienst WAYF Benutzerin ja (5) (6) Benutzerin berechtigt? (4) (9) Zugriff (7) gestattet ja nein verweigert (8) Heimateinrichtung Anbieter 1 19

  20. Wie funktioniert Shibboleth?(Folgekontakt gleicher Anbieter) (1) authentifiziert? (2) nein Benutzerin ja (9) Zugriff gestattet ja nein verweigert Heimateinrichtung Anbieter 1 Benutzerin berechtigt? 20

  21. Wie funktioniert Shibboleth?(Folgekontakt neuer Anbieter) (1) authentifiziert? (2) nein Lokalisierungsdienst Benutzerin ja (6) Benutzerin berechtigt? (4) (9) Zugriff (7) gestattet ja nein verweigert (8) Heimateinrichtung Anbieter 2 21

  22. Federated Identity Management Bestehende digitale Identitäten können auch ausserhalb einer Organisation für Authentisierung und Autorisierung genutzt werden Bestehendes Vertrauen Föderation Heim Organisation Ressourcen SP Service Providers IdP Identity Providers

  23. Identity Management • Kein Federated Identity Managementohne lokales Identity Management ! • Damit eine Universität AAI sinnvoll nutzen kannbenötigt sie ein lokales Identity Management • Prozesse für Eintritte / Mutationen / Austritte • Datenzusammenführung (Meta-Directory) • Verzeichnisdienst

  24. Identity Providermit AAI AAI AuthentisierungsSystem BenutzerVerzeichnis Identity Provider Integration • Unterstützte Schnittstellen: • Authentisierungs System • Alle die mit Apache oder Tomcat integriert werden können • Unter Windows: • Kerberos AuthN mit Active Directory • Windows AuthN mit IIS • Benutzerverzeichnis • JNDI (z.B. OpenLDAP, AD) • JDBC (SQL Datenbanken) Der Shibboleth IdP ist in Java geschrieben AuthN = Authentisierung

  25. Service Providermit AAI Web Server AAI WebAnwen-dung Service Provider Integration • Normalfall • Web Server: • Apache 1 & 2 • Tomcat via mod_jk • Microsoft IIS Autorisierung (AuthZ) • Anwendungen werden durchRegeln geschützt • Anwendungen verwenden die Benutzer-Attribute zur Zugangsbeschränkung Der Shibboleth SP ist in C++ geschrieben Shibboleth 2 bringt zusätzlich Java SP

  26. SAML Security Assertion Markup Language • OASIS Standard http://www.oasis-open.org • basiert auf XML • definiert das Format für Aussagen zu • Identitäten • Attribute • Berechtigungen • SAML 2.0 (2005) basiert auf Praxis-Erfahrung von • Liberty Alliance http://www.projectliberty.orgID-FF Identity Federation Framework • Shibboleth http://shibboleth.internet2.edu • Steigende Akzeptanz

  27. Interoperabilität Koordination ist das non-plus-ultra ! • Bilaterale Interoperabilität ist möglich, skaliert aber nicht • Bestehendes Vertrauen zwischen Organisationensoll für AAI gesichert werden: • Verträge, Vereinbarungen und Regeln • Technische Vorkehren: • Verwendete Standards • Digitale Server Zertifikate (X.509)für geschützte Kommunikation • Konfigurationsdaten der akzeptierten Partner • Interpretation der auszutauschenden Daten • Persönliches Netzwerk der Beteiligten

  28. Stand Shibboleth International • Etablierte nationale FöderationFinnland (HAKA), Schweiz (SWITCHaai), USA (InCommon) • Nationale Föderation im Werden • im AufbauUK (Access Management Federation) • in VorbereitungAustralien(MAMS Testbed)Dänemark, Deutschland, Schweden (SWIF) • Koordination um regionale AktivitätenBelgien, Frankreich (CRU) • Wachsendes Interesse in weiteren Ländern,aber noch keine Entscheidungen bekannt

  29. AAI neben Shibboleth? • Etablierte nationale Föderation • Kroatien (AAI@EDU.HR)Proprietäre Lösung um LDAP • Niederlande (SURFnet)Verwendet A-Select, kann nun auf Shibboleth SP zugreifen • Norwegen (FEIDE)Verwendet Moria, wechselt zu SAML 2 (Sun Identity Provider), Zugriff auf Shibboleth SP geplant • Spanien (RedIRIS)Verwendet PAPI, Zugriff auf Shibboleth SP geplant

  30. ArtSTOR Blackboard Bodington.org CSA Darwin Streaming Server Digitalbrain PLC eAcademy EBSCO Publishing Elsevier Science Direct ExLibris-SFX Fedora Higher Markets Horde Hupnet ILIAS JSTOR Moodle Napster NSDL OCLC OLAT Ovid Technologies Inc. Proquest Information and Learning Serials Solutions SYMPA ThomsonGale TWiki Useful Utilities-EZproxy Web Assign WebCT Unterstützung von Shibboleth bei Dienstanbietern Index of Shibboleth-Enabled Applications and Services (Quelle: internet2) in Deutschland: • Infoconnex • vascoda • ReDI • SaxIS • FIZ-Technik • FIZ-Karlsruhe 30

  31. Übersicht • Motivation AAI • Der Lösungsansatz Shibboleth • Die Projekte SWITCHaai und AAR (DFN-AAI) • Die Föderation • Rechtliche und organisatorische Rahmenbedingungen • Schritte zur Umsetzung 31

  32. Das SWITCHaai Projekt • Die Stiftung SWITCH • SWITCHaai • Projektverlauf • Projektstand • Die Virtuelle Heim Organisation – VHO • Projektfinanzierung

  33. Die Stiftung SWITCH • SWITCH ist eine Stiftung des Bundes und derHochschul-Kantone • Teleinformatikdienste für Lehre und Forschung • Netzwerk: Planung & Betrieb des Backbones • NetServices: e-Conferencing & Content Delivery • Security: CERT, PKI & Middleware (AAI, Grid & Roaming) • Domain Registration für .ch und .li • Total 70 Mitarbeiter • Outsourcing für Helpdesk und Billing der Domain Registration

  34. SWITCHaai Projektverlauf 2001 2002 2003 2004 2005 2006 2007 Studie Pilot Implementation Produktiver Betrieb Studie, Planung … Architektur Evaluation Shibboleth Nov 1999: Term AAI das erste Mal in einem Dokument verwendet Nov 2000: AAI Workshop

  35. VHO IdP in Betrieb IdP im Aufbau SWITCHaai Identity Providers Abdeckung: 140’000 Benutzer(> 70%) der CH Hochschulen Universitätsspital Zürich Universität Basel Zürcher Hochschule Winterthur Universität St. Gallen Universität Zürich ETH Zürich SWITCH Pädagogische Hochschule Bern Université de Neuchâtel Universität Luzern Universität Bern Fachhochschule Zentralschweiz Université de Fribourg HES-SO EPFL Université de Lausanne Université de Genève SUPSI Università della Svizzera italiana VHO = Virtual Home Organization

  36. Service Provider in SWITCHaai E-Learning Bibliotheken OLAT WebCT Vista EZproxy JSTOR VITELS WebCT Campus ScienceDirect dokeos DOIT ILIAS RERO Moodle EBSCO BSCW AD Learn Blackboard Andere Web Anwendungen kommerziell eConf-Portal SwissLex Fedora Microsoft CompiCampus Bundesgericht EVA jahia SAP-CM uPortal WebSMS Lenya IS-Academia

  37. Pilot Realisierung Betrieb Aufwand Tarife Bundesmittel SWITCH & Universitäten 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 Projektfinanzierung Grafik ist qualitativ, nicht quantitativ

  38. Das Projekt AAR(UB Freiburg, UB Regensburg) Projektauftrag BMBF (PT-NMB+F ): Es werden die notwendigen Komponenten und kommunikations-prozeduren für Authentifizierungsserver, Autorisierungsserver und Rechteserver definiert, entwickelt und im realen Betrieb eingesetzt und erprobt (mit Shibboleth). Weiterhin wird ein Organisationsmodell erarbeitet, dass den weiteren Betrieb nach der Projektlaufzeit sicherstellt. • Zeitraum: 1.1.2005 – 31.12.2007 • Kosten: rd. 380.000,- Eur (2 Stellen + Sachmittel) Auftragserweiterung für 2007: Aufbau einer Föderation zum Betrieb der AAI gemeinsam mit dem DFN. 38

  39. Zeitplan des Projekts AAR 29. Mai 2006 39

  40. Übersicht • Motivation AAI • Der Lösungsansatz Shibboleth • Die Projekte SWITCHaai und AAR (DFN-AAI) • Die Föderation • Rechtliche und organisatorische Rahmenbedingungen • Schritte zur Umsetzung 40

  41. Föderation Was ist eine Föderation? • Gruppe von Organisationen • Akzeptieren gegenseitig Bestätigungen zu • Identitäten • Beschreibende Aussagen (Attribute) • Befolgen gemeinsameRegeln • Sind selbstständig • Nutzen gemeinsameStandards • Circle of Trust

  42. Aufgaben und Rollen (1) Basis Dienste einer Föderation • Koordination, Strategie und Weiterentwicklung • Dokumentation & Metadaten bereitstellen • Beratung, Training • Betrieb des zentralen WAYF • Betrieb der Test Infrastruktur • Bereitstellen von Werkzeugen • Update Scripts • Resource Registry WAYF = 'Where Are You From?' Server

  43. Aufgaben und Rollen (2) Erweiterte Dienste einer Föderation • Unterstützung bei der Integration von Anwendungen • Unterstützung der Identity Provider • evtl. Outsourcing anbieten • Virtuelle Heim Organisation

  44. Föderations Mitglied Home Org SP Admin Einige Benutzer ohne Identity Provider Benutzer Admin VHO Dienst @SWITCH User Dir VHO Policy Virtuelle Heim Organisation – VHO • Integration von Benutzern ohne Identity Provider • SP Admin erzeugt bei der VHO “AAI-enabled” Kontenfür die Benutzer ohne Identity Provider • Ein VHO Konto ist nur für die SP von Nutzen,die der SP Admin kontrolliert.Dritte werden diesen Identitäten nicht trauen

  45. Die SWITCHaai Föderation • SWITCH ist der Betreiber der SWITCHaai Föderation • Mitglied der Föderation durch Unterschreiben des Service Agreements

  46. Regeln, Richtlinien und Zertifikate • Federation Policy • VHO Policy • Policy für akzeptierte Zertifikate • Attribut Spezifikation • Anforderungen ans Identity Management • 'Best Practice' Dokumente

  47. Datenschutz 1 (Datenhaltung) Europäisches Recht (Art. 6):PersonenbezogeneDaten dürfen nur für spezielle Aufgaben verarbeitet werden! • Die Einrichtungen (= Identitiy Provider) müssen den Zweck der Datenhaltung festlegen und beschreiben. In Universitäten z.B. (verkürzt): Unterstützung von Forschung und Lehre. • Die Ziele aller Mitglieder einer Föderation müssen diesem Zweck entsprechen! (Bei Unis u.a. ist das per se so) Auf Seiten der (auch kommerziellen) Dienstanbieter (SP): • Z.B. Buchhandel, ZS-Verlage, wiss. Infodienste: Ja • Z.B. EBAY, Kaufhäuser: Einschränkungen möglich • Behörden: ? 47

  48. Datenschutz 2 (Weitergabe von Attributen) Europäisches Recht (Art. 7): Weitergabe personenbezogener Daten nur wenn notwendig • Zur Vertragserfüllung (mit den Anbietern) • Gesetzliche Grundlagen vorliegen • Zum Schutz vitaler Interessen (der Anbieter) • Zur Erfüllung der Leistung eines Auftrages (des Anbieters) • und 5. Nach ausdrücklicher Zustimmung der betroffenen Person 48

  49. Weitergabe von Attributen: Das Modell Autograph (MAMS) • Die Attribute, die an einen Service-Provider weitergegeben werden, werden denBenutzern in Form von Visitenkartenprä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 • Demo 49

  50. Metadaten Metadaten sind fundamental für die Föderation! • Vertrauen & Sicherheit • Infos über Zertifikate und providerID,damit man weiss mit wem man Daten austauscht • Datenschutz • Attribute Release Policy (beim IdP) • Metadaten müssen aktuell und synchron sein,sonst klappt die Interoperabilität nie • Bilateraler Austausch skaliert schlecht  Ein Werkzeug für die Verwaltung der Metadaten wird benötigt

More Related