Authentifizierung Autorisierung und Rechteverwaltung Re DI als Pilotanwendung

Authentifizierung, Autorisierung und Rechteverwaltung Re. DI als Pilotanwendung für Shibboleth 2. Shibboleth-Workshop Freiburg, 23. März 2006 Bernd Oberknapp, UB Freiburg

Was ist Re. DI? • Die Regionale Datenbank-Information (Re. DI) 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 • Re. DI: zentraler Dienstleister für alle (technischen) Fragen rund um das Datenbankenangebot • Konsortium Baden-Württemberg: Einkaufsgemeinschaft der Bibliotheken Bernd Oberknapp, UB Freiburg 2

Re. DI: Aktueller Stand • 490 Datenbanken aller Fachrichtungen im Angebot, darunter 335 Windows-Datenbanken und Cross. Fire 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 Suchanfragen pro Jahr • erhebliche Synergien bei Betrieb und Betreuung, Hardwareeinkauf und Datenbanklizenzierung Bernd Oberknapp, UB Freiburg 3

Aktuelle Re. DI-Authentifizierung • Benutzer werden über ein für Re. DI entwickeltes, verteiltes System über lokale Benutzerdatenbanken authentifiziert und autorisiert. • Re. DI-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, Bi. Ber, SISIS, . . . ) – 20 Einrichtungen (teilweise parallel zu Horizon) über den zentralen Re. DI-Authentifizierungsserver • Re. DI-Authentifizierung wird genutzt für: Re. DI, Cross. Fire, Elektra, ESem, . . . Bernd Oberknapp, UB Freiburg 4

Aktuelle Re. DI-Authentifizierung Uni Stuttgart Re. DI-Server Re. DI-Login • Benutzerkennung • Passwort • Einrichtungsauswahl IBplus. Server Re. DI-Server Bernd Oberknapp, UB Freiburg IBplus. Auth. Server Benutzerdaten FH Heilbronn IBplus. Auth. Server Benutzerdaten . . . Einrichtungen 5

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 Re. DI-Verfahren ist proprietär und für einige Dienste/je nach Installation nicht sicher genug. • Lösung: Shibboleth Bernd Oberknapp, UB Freiburg 6

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 Re. DI 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 7

1. Schritt: Zentrale Installation • Im ersten Schritt zentrale Implementierung aller Shibboleth-Komponenten in Re. DI: – Re. DI als Service Provider (zusätzlich zu den anderen Re. DI-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 8

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

Zentrale Identity-Provider • 62 Identity-Provider implementiert und in interne Re. DI-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 10

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

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

Re. DI als SP: Technik II • Nach erfolgreicher Authentifizierung des Benutzers am Id. P stellt der SP /shib/login. php die Attribute über HTTP-Header zur Verfügung: – edu. Person. Entitlement (vgl. Attribute-Vortrag) – edu. Person. Principal. Name (für Testphase) • /shib/login. php baut damit eine Re. DI-Sitzung auf, alles weitere übernimmt dann wie bisher Re. DI. • Apache-Konfiguration: Auth. Type Shibboleth Require Shibboleth Bernd Oberknapp, UB Freiburg 13

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

2. Schritt (optional): Übernahme der Id. Ps 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 direkt, ohne das IBplus-Protokoll, erfolgen. • Dies ermöglicht dann auch die Nutzung von Service-Providern mit anderen Attribut. Anforderungen (Benutzergruppen) als Re. DI. • Re. DI ist dann aus Shibboleth-Sicht nur noch ein Service-Provider. Bernd Oberknapp, UB Freiburg 15

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

„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 17