Integration der Universitätsbibliothek an der Freien Universität Berlin in die IDMS-Infrastruktur

Transkript

1 Steffen Hofmann (Dipl.-Inf.) ZEDAT, Identity and Customer Management (ICM) Integration der Universitätsbibliothek an der Freien Universität Berlin in die IDMS-Infrastruktur Account-Migration oder System-Integration

2 Inhalt Stand IDMS-Anbindung FU-Account vs. UB-Account ExLibris-Produkte Account-Migration? Account-Provisionierung Shibboleth-Anbindung Fazit Weitere Schritte Diskussion 2

3 Ausgangssituation IDMS Rechenzentrum (ZEDAT) betreibt zentrales IDMS (FUDIS) U.a. Ziel von FUDIS: Ein Account für alle Dienste Anbindung vieler IT-Systeme an FUDIS bereits erfolgt 3

4 Ausgangssituation IDMS-Verbreitung Bereich Status (geschätzt) ZEDAT >99% Verwaltung (inkl. CeDiS, eas, Studierendenverwaltung) >90% Fachbereich Wirtschaftswissenschaft >90% Fachbereich Mathematik und Informatik >90% Fachbereich Physik >90% Fachbereich Geschichts- und Kulturwissenschaften >90% Fachbereich Rechtswissenschaft ~70% Fachbereich Veterinärmedizin ~30% Fachbereich Biologie, Chemie, Pharmazie ~30% Universitätsbibliothek ~20% 4

5 Ausgangssituation Universitätsbibliothek Druck wächst, von rein IP-basierten Zugriffen auf Ressourcen (Verlage etc.) zu Shibboleth-basierten Lösungen zu wechseln Shibboleth mit FU-Account bereits möglich, aber das reicht nicht keine vollständige Überlappung der Nutzergruppen der UB und in FUDIS, da u.a. die UB alle Bürger aus Berlin und Speckgürtel in Brandenburg zulässt ~ UB-Accounts versus ~ FU-Accounts UB-Accounts besitzen meist keine Kopplung zu FU-Accounts über einen verlässlichen Identifier, Ausnahme: Studierende der FUB und Charité über Matrikelnummer UB-Accounts für Studierende der FUB und Charité werden aus Textdatei generiert, die FUDIS einmal pro Woche liefert; also auch nicht optimal UB setzt Produkte von ExLibris ein, u.a. Aleph 5

6 Schnittmenge Nutzer UB und FUDIS 6

7 Nutzergruppen der UB diverse kleine Sondergruppen 0,4% Externe Institute 0,3% Externe 24,8% Institute der FUB 0,3% Hochschullehrer FUB 0,6% Gäste FUB 1,9% Wissenschaftliche Mitarbeiter FUB 4,6% Studierende anderer Hochschulen 26,1% Studierende Charité 6,7% Stand: September 2011 Studierende FUB 34,4% 7

8 Verwendete Produkte von ExLibris 8

9 Account-Migration? Zentrale Frage: Sollen alle UB-Accounts nach FUDIS migriert werden? (also auch alle Bürger aus Berlin/Brandenburg, die sonst keine weitere Verbindung zur Universität besitzen) Antwort: Keine Migration von UB-Accounts von Nicht-Universitätszugehörigen Universitätszugehörige mit FU-Account sollen nicht mehr den UB- Account nutzen (müssen) UB-Accounts sollen mit traditioneller ID in Aleph erhalten bleiben und in vergleichbarer Form für neue Nutzer angelegt werden 9

10 Keine vollständige Account-Migration - Gründe Gründe u.a.: Accounts von Nicht-Universitätszugehörigen werden (aktuell) bei keinem andern IT-System benötigt Bereinigung von gleichnamigen Accounts sehr aufwändig Prozesse und Werkzeuge zum Verwalten der UB-Accounts bereits mit Aleph in der UB vorhanden Datenschutz: Zustimmung der Betroffenen (Nicht-Universitätszugehörige) für die Daten zu den UB-Accounts wurde nur für die Nutzung innerhalb der UB erteilt 10

11 Eigenschaften Aleph / X-Service In Aleph können neben einer primären ID noch drei weitere IDs zu einem UB-Account gepflegt werden X-Service ist REST Webservice (REST=REpresentational State Transfer Architektur) für die Provisionierung von UB-Accounts Ergebnis einer X-Service-Anfrage mit einer sekundären ID enthält immer (auch) die primäre ID Problem beim X-Service: Die Aleph internen Datenstrukturen müssen sehr gut bekannt sein; keine Orientierung an einem Standardschema wie inetorgperson u.a. 11

12 Provisionierung FUDIS UB Webservice anstelle von Textdatei für zeitnahe Provisionierung X-Service wird von FUDIS nicht direkt verwendet UB stellt SOAP-Webservice bereit: Schema orientiert sich an Standards SOAP-Webservice benutzt als Backend den X-Service Aufwändige Umsetzungslogik vom FU-Account zum UB-Account wird im SOAP- Webservice abgebildet Klare Trennung der Verantwortlichkeiten Sekundäre ID-Zuweisung in Aleph: ID-2: Barcode (vom Bibliotheks-/Studentenausweis) ID-3: Matrikelnummer oder Personalnummer ID-4: FU-Accountname Verknüpfung von UB- und FU-Account für Nicht-Studierende der FUB und Charité sehr schwierig: Z.T. über Vorname, Nachname, Geburtsdatum (wenn vorhanden) halt die üblichen Probleme bei Migrationen 12

13 Shibboleth-Anbindung PDS unterstützt Shibboleth, verlangt aber als primäre ID des UB-Accounts als Application-ID Shibboleth-Integration des PDS nach Softwareupdates z.t. mit Fehlern Keine X-Service-Datenkonnektoren und -JAAS-Module für Shibboleth Aleph verwendet als Backend Oracle-Datenbank Zugriff mit Standarddatenkonnektor per JDBC technisch möglich, aber aus Sicherheitsgründen nicht gewollt Resultat: Datenkonnektor und JAAS-Modul für X-Service wurden selbst entwickelt bzw. implementiert 13

14 Discovery Service als Accountweiche 14

15 Stufenweise Umstellung 15

16 Fazit und weitere Schritte Fazit: Lösung stellt eher föderative IT-Systemintegration dar und weniger eine klassische Account-Migration Stufenweise Umstellung nach Nutzergruppen ist sanft, aber auch nicht anders möglich PDS und X-Service müssen sich im Normalbetrieb noch beweisen, bisher nur Testbetrieb und noch nicht alle Entwicklungen abgeschlossen Projekt wird frühestens Ende 2012 abgeschlossen sein Weitere Schritte: Abschluss der Entwicklungsarbeiten, Lasttests, Produktionsbetrieb Umstellung von IP-basierten Zugriffen auf Verlagsressourcen zu Shibbolethbasierten Zugriffen Einsatz von Reverse Proxy mit Shibboleth für Ressourcen, die kein Shibboleth unterstützen (z.b. kleine Verlage) 16

17 Ende, Kontakt, Diskussion Vielen Dank! 17