1 / 21

Erfahrungsbericht aus dem AAR Projekt LRZ-München 9.02.2007 Franck Borel - UB Freiburg

Erfahrungsbericht aus dem AAR Projekt LRZ-München 9.02.2007 Franck Borel - UB Freiburg. Übersicht. AAR-Projekt Umstellung von ReDI auf Shibboleth DFN-AAI Aktueller Stand Ziele Support von Einrichtungen und Anbietern. Eckdaten zum AAR-Projekt. Partner: UB Freiburg und UB Regensburg

kynan
Download Presentation

Erfahrungsbericht aus dem AAR Projekt LRZ-München 9.02.2007 Franck Borel - UB Freiburg

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. Erfahrungsbericht aus dem AAR Projekt LRZ-München 9.02.2007 Franck Borel - UB Freiburg

  2. Übersicht • AAR-Projekt • Umstellung von ReDI auf Shibboleth • DFN-AAI • Aktueller Stand • Ziele • Support von Einrichtungen und Anbietern 2

  3. Eckdaten zum AAR-Projekt • Partner: UB Freiburg und UB Regensburg • finanziert durch das BMBF (PT-NMB+F) • eingebettet in vascoda (http://www.vascoda.de/) • Laufzeit zunächst 3 Jahre bis Ende 2007: • 2 Jahre Entwicklungs- und Testphase mit der Regionalen Datenbank-Information Baden-Württemberg (ReDI) und vascoda als Pilotanwendungen • 1 Jahr Unterstützung von Einrichtungen und Anbietern bei der Einführung des Systems • Verlängerung bis Mitte 2008 bewilligt 3

  4. Was macht das AAR-Projekt? • AAR baut eine Infrastruktur zur Authentifizierung, Autorisierung und Rechteverwaltung (Lizenzrechte) • AAR implementiert ein Single Sign-on System, mit dem verschiedene Ressourcen mit einem einzigen Login genutzt werden können • AAR baut auf Shibbolethauf • AAR ergänzt Shibboleth um einen Rechteserver für Nutzungslizenzen (Teilprojekt UB Regensburg) • Unter Koordination des DFN wird eine deutschlandweite Föderation als Dienst des DFN aufgebaut (DFN-AAI). 4

  5. Warum Shibboleth? • einrichtungsübergreifendes Single Sign-On • Autorisierung und Zugriffskontrolle über Attribute mit der Möglichkeit zur anonymen/pseudonymenNutzung von Angeboten • basiert auf bewährter Software und Standards (SAML, XML, SOAP, TLS, XMLsig, XMLenc, HTTP) • Aufwand für Integration in die vorhandene lokale Umgebung und webbasierten Anwendungen in vielen Fällen vergleichsweise gering • Weltweithohe Akzeptanz, auch bei kommerziellen Anbietern (Elsevier, JSTOR, EBSCO, Ovid, Springer, GBI, CSA...) • Open-Source 5

  6. ReDI und Shibboleth • 565 Datenbanken aller Fachrichtungen im Angebot, darunter 340 Windows-Datenbanken und CrossFire Beilstein und Gmelin auf eigenen, gespiegelten Serversystemen in Freiburg und Stuttgart • 182 Angebote auf externen Verlagsservern • 62 teilnehmende Einrichtungen inklusive Gästen aus Bayern, Rheinland-Pfalz und Saarland • Anfragen aus NRW, Hessen und Sachsen • mehr als 3.000.000 Suchanfragen pro Jahr • erhebliche Synergien bei Betrieb und Betreuung, Hardwareeinkauf und Datenbanklizenzierung 6

  7. Früher: ReDI-Authentifizierung • Benutzer wurden über ein für ReDI entwickeltes, verteiltes System (IBplus) über lokale Benutzerdatenbanken authentifiziert und autorisiert. • ReDI-Authentifizierung wird genutzt von: • 21 Einrichtungen über Horizon-Benutzerdatenbanken(13 FHs, 2 PHs, 2 MHs und 2 BAs über das BSZ) • 6 Einrichtungen über andere Benutzerdatenbanken(LDAP, SQL, BiBer, SISIS, ...) • 20 Einrichtungen (teilweise parallel zu Horizon)über den zentralen ReDI-Authentifizierungsserver • ReDI-Authentifizierung wird genutzt für:ReDI, CrossFire, Elektra, ESem, ... 7

  8. Probleme des „alten“ Systems • Kein Single Sign-On: Bei allen Diensten wird derselbe Account verwendet, der Nutzer muss sich aber trotzdem bei jedem Dienst neu einloggen. • Jeder Dienst verwendet eine eigene Login-Maske: • der Nutzer muss Benutzerkennung und Passwort jedem einzelnen Dienst anvertrauen • der Wiedererkennungswert ist gering • Das ReDI-Verfahren ist proprietär und für einige Dienste/je nach Installation nicht sicher genug. • Lösung:Shibboleth 8

  9. Umstellung auf Shibboleth: Zentrale Installation • Ziel war eine möglichst kurzfristige, flächendeckende Verfügbarkeit von Shibboleth, deshalb: • Die Authentifizierung und Autorisierung wurde für alle an ReDI teilnehmenden Einrichtungen auf einmal auf Shibboleth umgestellt. • 62 Identity-Provider wurden implementiert und in interne ReDI-Föderation (aar) eingebunden • Zugriff auf Benutzerdatenbanken erfolgt zunächst auch für Shibboleth über das IBplus-Protokoll, in den Einrichtungen sind daher keine Änderungen erforderlich! • Hauptaufgaben für ReDI/AAR waren: • Authentifizierung und Autorisierung trennen • Datenbank zur Verwaltung der Attribute 9

  10. ReDI Baden-Württemberg: heute • Die Teilnehmer in Baden-Württemberg und Gäste aus: • Rheinland-Pfalz, Saarland und Bayern • Anfragen aus Sachsen, Hessen und NRW • Crossfire-Nutzung aus • Bayern seit 2001 IdP Alle IdPs 10

  11. 2. Schritt (optional): Übernahme der IdPs durch die Einrichtungen • Im zweiten Schritt können die Einrichtungen(bei Horizon-Bibliotheken das BSZ) den Betrieb des Identity Providersselbst übernehmen. • Der Zugriff auf die Benutzerdatenbanken kann dann direkt, ohne das IBplus-Protokoll, erfolgen. • Dies ermöglicht dann auch die Nutzung von Service-Providern mit anderen Attribut-Anforderungen (Benutzergruppen) als ReDI. • ReDI ist dann aus Shibboleth-Sicht nur noch ein Service-Provider. 11

  12. ReDI Baden-Württemberg: In Kürze • Die Teilnehmer in Baden-Württemberg und Gäste aus: • Rheinland-Pfalz, Saarland und Bayern • Anfragen aus Sachsen, Hessen und NRW • Crossfire-Nutzung aus • Bayern seit 2001 IdP einige IdP Horizon IdP 12

  13. ReDI Baden-Württemberg: Ziel • Die Teilnehmer in Baden-Württemberg und Gäste aus: • Rheinland-Pfalz, Saarland und Bayern • Anfragen aus Sachsen, Hessen und NRW • Crossfire-Nutzung aus • Bayern seit 2001 IdP wenige IdP Horizon IdP 13

  14. Stand und Ausblick zum Projekt • Alle Komponenten von Shibboleth sind in einer Testumgebung verfügbar • ReDI wurde auf Shibboleth umgestellt (mit einer „internen“ Föderation, 62 Identity Provider) • Die Betriebssoftware IPS von vascoda ist auf Shibboleth umgestellt und wird seit Dezember 2006 in Freiburg eingesetzt. • Für den Bereich der Nationallizenzen wird z.Zt. eine VHO als Grundlage zur Einführung von Shibboleth aufgebaut (GBV). • 28. Februar 2007 wird der 4. Workshop zu Shibboleth in Berlin stattfinden (DFN Betriebstage). 14

  15. DFN-AAI • Unter Koordination des DFN entsteht eine deutschlandweite Föderation unter dem Namen DFN-AAI • Am 14. März 2006 wurde in Berlin eine Arbeitsgruppe zum Aufbau der Föderation gebildet. Mitglieder sind: DFN, AAR, Bibliotheken, GRID-Gruppen, CERT, RZ‘s, u.a. • DFN und AAR haben internationale Kontakte zu Internet2, Switch, Haka, MAMS. Das Projekt ist koordiniert mit anderen europäischen Aktivitäten (z.B. Terena, Geant2). 15

  16. DFN-AAI • Aktueller Stand: • Die Geschäftstelle des DFNs in Stuttgart baut die Infrastruktur auf: • WAYF • Testumgebung (läuft momentan in Freiburg) • Administrations-Werkzeuge für die Metadaten • Support (übernimmt zur Zeit das AAR-Team) • Die Arbeitsgruppe der DFN-AAI entwirft Richtlinien für die Attribute und arbeitet die Vertragsbedingungen für Einrichtung Anbieter aus • Das DFN arbeitet die rechtlichen Grundlagen und das Geschäftsmodell aus • Das AAR-Team hat Beratungsfunktion (Technik, Strategie, Architektur, Datenschutz) 16

  17. DFN-AAI • Ziele: • In den nächsten Monaten soll die Testumgebung in Stuttgart laufen • Ab Juni Pilotphase mit verschiedenen Einrichtungen • Ende 2007 Startschuss DFN-AAI 17

  18. Erfahrungen beim Support • AAR betreibt eine Testumgebung • Das AAR-Team hilft bei der Integration von bestehenden System in Shibboleth (Einrichtungen und Anbieter) • Entwicklung von Schnittstellen (z.B. SOAP-Resolver, JAAS-Schnittstellen) 18

  19. Erfahrungen beim Support • 80% der Probleme bei der Integration sind Verständnisprobleme (nein Shibboleth ist kein IdM :-)) • Problem IdM: Es wird versucht mit Shibboleth, die Unzulänglichkeiten der Benutzerverwaltung auszugeleichen (Bsp. mehrere IdMs mit Shibboleth zu koppeln) • Kommunikationsprobleme (z. B. RZ und UB sprechen nicht miteinander) • Technisches Verständnis fehlt häufig und muss erst angeeignet werden (Shibboleth besteht aus einer Vielzahl von Komponenten, was die Sache nicht vereinfacht) • Dokumentation noch nicht ausgereift • Fehlende Werkzeuge (z.B. müssen die Metadaten immer noch von Hand eingetragen werden = hohe Fehlerrate) • Zertifikate (Bsp. openSSL auf manchen Plattformen problematisch, keine geeingneten Zertifikate) • Vorbehalte gegenüber neuer Technik: Was der Bauer nicht kennt… :-) 19

  20. Erfahrung mit eigenen Intergrationen • ReDI läuft seit September 2006 fehlerfrei! • Auch komplizierte Lösungen haben wir integrieren können (z. B. Authentifizierung und Autorisierung über SOAP-Schnittstelle, Anbindung an IBPlus) • Gute Strategie: • Mit einfachen internen Anwendungen anfagen • Templates • Einfach machen :-)! 20

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

More Related