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

Was ist ReDI? Die Regionale Datenbank-Information (ReDI) ist ein vom Ministerium für Wissenschaft, Forschung und Kunst geförderter kooperativer Dienst fü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

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

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

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

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

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

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 Provider fü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

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

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

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

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

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 Shibboleth Require Shibboleth </Location> Bernd Oberknapp, UB Freiburg

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

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 Providers selbst ü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

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

„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