ReDI als Pilotanwendung für Shibboleth

Präsentation zum Thema: "ReDI als Pilotanwendung für Shibboleth"—  Präsentation transkript:

1 ReDI als Pilotanwendung fü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 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

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 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
. ReDI-Server Einrichtungen IBplusAuthServer Benutzerdaten Uni Stuttgart Benutzerkennung Passwort Einrichtungsauswahl ReDI-Login IBplusServer FH Heilbronn 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 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

9 1. Schritt: Zentrale Installation
ReDI-Server Einrichtungen Benutzerdaten Uni Stuttgart Einrichtungsauswahl ReDI-Login FH Heilbronn SSO AA IBplusAuthServer . . . . 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 Shibboleth Require Shibboleth </Location> Bernd Oberknapp, UB Freiburg

14 Demo ReDI ohne Shibboleth: http://www.redi-bw.de/?prefs[shib]=0
ReDI mit Shibboleth (im Testbetrieb): ReDI mit Shibboleth im Debug-Modus: 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 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

16 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

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