ReDI als Pilotanwendung für Shibboleth 2. Shibboleth-Workshop Freiburg , 23 . M ärz 2006

1. ReDI als Pilotanwendungfür Shibboleth 2. Shibboleth-Workshop Freiburg, 23. März 2006 Bernd Oberknapp, UB Freiburg

2. Was ist ReDI? • Die Regionale Datenbank-Information (ReDI) ist ein vom Ministerium für Wissenschaft, Forschung und Kunst geförderter kooperativer Dienstfür die staatlichen Hochschulen und Landesbibliotheken in Baden-Württemberg. • Ziel beim Aufbau war die nachhaltige Verbesserung der flächendeckenden Fachinformationsversorgung • ReDI: zentraler Dienstleister für alle (technischen) Fragen rund um das Datenbankenangebot • Konsortium Baden-Württemberg: Einkaufsgemeinschaft der Bibliotheken Bernd Oberknapp, UB Freiburg

3. ReDI: Aktueller Stand • 490 Datenbanken aller Fachrichtungen im Angebot, darunter 335 Windows-Datenbanken und CrossFire Beilstein und Gmelin auf eigenen, gespiegelten Serversystemen in Freiburg und Stuttgart • 62 teilnehmende Einrichtungen inklusive Gästen aus Bayern, Rheinland-Pfalz und Saarland • mehr als 3.000.000 Suchanfragen pro Jahr • erhebliche Synergien bei Betrieb und Betreuung, Hardwareeinkauf und Datenbanklizenzierung Bernd Oberknapp, UB Freiburg

4. Aktuelle ReDI-Authentifizierung • Benutzer werden über ein für ReDI entwickeltes, verteiltes System ü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, ... Bernd Oberknapp, UB Freiburg

5. Aktuelle ReDI-Authentifizierung Uni Stuttgart IBplusAuthServer Benutzerdaten ReDI-Server FH Heilbronn ReDI-Login IBplusAuthServer • Benutzerkennung • Passwort • Einrichtungsauswahl Benutzerdaten IBplusServer . . . ReDI-Server Einrichtungen Bernd Oberknapp, UB Freiburg

6. Probleme des aktuellen 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 Bernd Oberknapp, UB Freiburg

7. Umstellung auf Shibboleth Ziel ist eine möglichst kurzfristige, flächendeckende Verfügbarkeit von Shibboleth, deshalb: • Die Authentifizierung und Autorisierung wird für alle an ReDI teilnehmenden Einrichtungen auf einmal auf Shibboleth umgestellt. • Alle dafür notwendigen Komponenten werden zunächst zentral installiert. • Die Einrichtungen können den Betrieb der Komponenten dann später selbst übernehmen. Bernd Oberknapp, UB Freiburg

8. 1. Schritt: Zentrale Installation • Im ersten Schritt zentrale Implementierung aller Shibboleth-Komponenten in ReDI: • ReDI als Service Provider (zusätzlich zu den anderen ReDI-Authentifizierungsverfahren) • Identity Providerfür alle Einrichtungen • Zugriff auf Benutzerdatenbanken erfolgt zunächst auch für Shibboleth über das IBplus-Protokoll, in den Einrichtungen sind daher keine Änderungen erforderlich! Bernd Oberknapp, UB Freiburg

9. 1. Schritt: Zentrale Installation FH Heilbronn Uni Stuttgart SSO AA IBplusAuthServer ReDI-Server Benutzerdaten ReDI-Login Einrichtungsauswahl FH Heilbronn Uni Stuttgart IBplusAuthServer SSO AA Benutzerdaten . . . . . . ReDI-Server Einrichtungen Bernd Oberknapp, UB Freiburg

10. Zentrale Identity-Provider • 62 Identity-Provider implementiert und in interne ReDI-Föderation (aar) eingebunden • Wesentliche Entwicklungsaufgaben: • Anbindung an die lokalen Benutzerdatenbanken über das vorhandene IBplus-Protokoll • Authentifizierung und Autorisierung trennen • Funktionalität des IBplus-Systems nachbilden:IP-Adressen und Fehlermeldungen durchreichen • Rechtedatenbank zur Verwaltung der Attribute Bernd Oberknapp, UB Freiburg

11. ReDI als Service-Provider • Service-Provider auf den ReDI-Servern installiert und in Föderation eingebunden • Anpassung der ReDI-Software war einfach: • Neues Authentifizierungsverfahren „extern“ • Zuordnung der Benutzer zu den ReDI-Benutzergruppen über entsprechende Attribute • Zentrales Login-Skript ersetzt durch WAYF • Wesentliche Entwicklungsaufgabe: WAYF • Single-Logout erst mit Shibboleth 2.0! Bernd Oberknapp, UB Freiburg

12. ReDI als SP: Technik I • ReDI verwendet „Lazy Authentication“:Die Authentifizierung erfolgt erst, wenn dies notwendig ist oder der Benutzer es wünscht. • Wird die Authentifizierung ausgelöst, erfolgt ein Redirect zum ReDI-WAYF: /shib/login.php • Die Authentifizierung für die vom Benutzer gewählte Einrichtung wird von ReDI über die SessionInitiator-URL des SP angestossen: /Shibboleth.sso/WAYF/aar?target=<ReDI-Rücksprungadresse>&providerId=<Provider-ID der Einrichtung> Bernd Oberknapp, UB Freiburg

13. ReDI als SP: Technik II • Nach erfolgreicher Authentifizierung des Benutzers am IdP stellt der SP /shib/login.php die Attribute über HTTP-Header zur Verfügung: • eduPersonEntitlement (vgl. Attribute-Vortrag) • eduPersonPrincipalName (für Testphase) • /shib/login.php baut damit eine ReDI-Sitzung auf, alles weitere übernimmt dann wie bisher ReDI. • Apache-Konfiguration:<Location /shib>AuthType ShibbolethRequire Shibboleth</Location> Bernd Oberknapp, UB Freiburg

14. Demo • ReDI ohne Shibboleth:http://www.redi-bw.de/?prefs[shib]=0 • ReDI mit Shibboleth (im Testbetrieb):http://www.redi-bw.de/?prefs[shib]=1 • ReDI mit Shibboleth im Debug-Modus:http://www.redi-bw.de/shib/login.php?debug=1 Bernd Oberknapp, UB Freiburg

15. 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. Bernd Oberknapp, UB Freiburg

16. 2. Schritt (optional): Übernahme der IdPs durch die Einrichtungen Uni Stuttgart ReDI-Server Benutzerdaten ReDI-Login SSO AA Einrichtungsauswahl FH Heilbronn SSO AA Benutzerdaten . . . ReDI-Server Einrichtungen Bernd Oberknapp, UB Freiburg

17. „Migrationscheckliste“ • Wie werden die Ressourcen bisher geschützt (Apache, Tomcat, eigenes Verfahren, ...)? • Existiert ein Sitzungsmanagement? • Kann dieses weiter verwendet werden, z.B. indem eine Sitzung über Shibboleth aufgebaut wird? • Existiert eine Rechteverwaltung? • Können die dafür notwendigen Informationen per Shibboleth über Attribute bereitgestellt werden? • Können die Identity-Provider die Attribute liefern? Bernd Oberknapp, UB Freiburg