Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Authentifizierung, Autorisierung und Rechteverwaltung ReDI als Pilotanwendung für Shibboleth 2. Shibboleth-Workshop Freiburg, 23. März 2006 Bernd Oberknapp,"—  Präsentation transkript:

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

2 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

3 3 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 Suchanfragen pro Jahr erhebliche Synergien bei Betrieb und Betreuung, Hardwareeinkauf und Datenbanklizenzierung

4 4 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,...

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

6 6 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

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

8 8 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!

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

10 10 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

11 11 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!

12 12 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= & providerId=

13 13 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: AuthType Shibboleth Require Shibboleth

14 14 Bernd Oberknapp, UB Freiburg Demo ReDI ohne Shibboleth: ReDI mit Shibboleth (im Testbetrieb): ReDI mit Shibboleth im Debug-Modus:

15 15 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.

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

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


Herunterladen ppt "Authentifizierung, Autorisierung und Rechteverwaltung ReDI als Pilotanwendung für Shibboleth 2. Shibboleth-Workshop Freiburg, 23. März 2006 Bernd Oberknapp,"

Ähnliche Präsentationen


Google-Anzeigen