Erfahrungen mit dem Betrieb des IBM Tivoli Identity Managers (ITIM) an der RWTH Aachen

Transkript

1 : Zentrale Verzeichnisdienste 15./16. Dezember 2004 in Ilmenau Erfahrungen mit dem Betrieb des IBM Tivoli Identity Managers (ITIM) an der RWTH Aachen Guido Bunsen, Michael Gebhardt, Michaela Schraad Rheinisch-Westfälische Technische Hochschule Aachen

2 Inhalt 1. Einführung Ausgangslage, Ziele, Architektur 2. Erfahrungen: Identitätsmanagement des RZ Überblick, Freischaltprozess für Studierende Quellsysteme: Anbindung der HR-Feeds Zielsysteme: Provisionierung neuer Dienste Wandel, Aufwände, Fazit 3. Ausblick: RWTH-Identitätsmanagement Was fehlt noch für die RWTH?.. und über die RWTH hinaus. 4. Zusammenfassung

3 1. Einführung 1. Einführung Ausgangslage, Ziele, Architektur 2. Erfahrungen: Identitätsmanagement des RZ Überblick, Freischaltprozess für Studierende Quellsysteme: Anbindung der HR-Feeds Zielsysteme: Provisionierung neuer Dienste Wandel, Aufwände, Fazit 3. Ausblick: RWTH-Identitätsmanagement Was fehlt noch für die RWTH?.. und über die RWTH hinaus. 4. Zusammenfassung

4 Die RWTH Aachen in Zahlen Professoren: 414 Mitarbeiter: ) Studenten: ) Studienkurse: ca. 80 Fakultäten: 9 Organisationseinheiten: ca. 650 Lehrstühle: ca. 350 Budget (total): Mio. Euro 3) Eingeworbene Mittel: Mio. Euro 3) ca. 750 Promotionen p.a. ca Neueinschreibungen p.a. hohe personelle Fluktuation heterogene Vorstellungswelten 1) in ) im WS 2002/2003 3) in 2003 Quelle: RWTH Aachen 03/2004, Dez. Planung, Entwicklung und Controlling

5 Ausgangslage, Beweggründe Steigende Zahl von Dienstleistungen mehrerer Dienstleister Traditionelle Dienste, neue Lehrund Lernformen Bibliothek Elektronische Medien, Zugänge zu kostenpflichtigen DB elektronische Verwaltungsabläufe (z.b. CAMPUS-Informationssystem) Telefonbuch, Hörsaalverwaltung, Bestellportale,... Terminkalender, Belegung von Kursen, virtuelles Prüfungsamt,... Herausforderung Mehrfache Registrierung von Personen Konsistenz, Mehrarbeit Löschung von Diensten nach Ausscheiden (z.b. aus Lizenzgründen) Rechtsverbindlichkeit Zeit ist bei der Bereitstellung von Diensten durchaus kritisches Element Eigenverständnis / -darstellung des RZ als moderner Dienstleister!

6 Dienstleistungen mehrer Anbieter: CAMPUS-Informationssystem Veranstaltungsorganisation Verzeichnisdienste Organisationsabläufe öffentliches Vorlesungsverzeichnis Vorlesungsplanung für Studierende (CAMPUS- Office) Virtuelles Zentrales Prüfungsamt Veranstaltungsverwaltung: Dozenten Fachstudienberater Dekane Lehrevaluation Telefonverzeichnis Organisationsverzeichnis Hörsaalverzeichnis Adressverzeichnis Verzeichnisverwaltung für Organisationseinheiten Hardwareportal Kooperationsdatenbank Alumninetzwerk Auszubildendenverwaltung Telefonvermittlung Telefonanlage Softwareportal Druckverzeichnisse Produkt: CAS- CAMPUS Neu 2004 CAMPUS-Plattform Web-, Applikations- und Datenbankservices Koordination der Erweiterung ZIEL: integrierte Dienstleistungen ZIEL: integrierte Dienstleistungen

7 Beispiel 1: Informationsfluss Hardwareportal (vereinfacht) Beschaffungsrichtlinien Organisationseinheiten Abt. 9.1 RZ Auftrag Angebot Rahmenvereinbarung Anbieter Systemspezifikationen Hardwareportal

8 Beispiel 2: Virtuelles Zentrales Prüfungsamt Früher: Anmeldung im ZPA erforderlich Anmeldelisten an Dozenten (Diskette), Nachmelder Notenaushang (Datenschutz?) Notenliste an ZPA (Diskette), Korrekturen Bescheinigung im ZPA abholen Mit VZPA Anmeldung online (Studierender, Dozent) Notenerfassung online Prüfungsleistung online Ersparnis/Komfortgewinn 2 Besuche beim ZPA entfallen Aktuelle Sicht für Studierende und Dozenten Diskette mit Anmeldeliste und Notenliste entfällt Kein Notenaushang erforderlich Integrationsprinzip: Zugriff auf relevante Daten ersetzt hin und her von Daten Integration bringt die wesentlichen Komfort- und Effizienzgewinne Integration bringt die wesentlichen Komfort- und Effizienzgewinne

9 Erwartungen und Ziele Definierte Prozesse Durchsetzung von Policies Rechte sollen rechtzeitig wieder entzogen werden Änderungen sollen nachvollziehbar sein (Auditing) Mehr Transparenz und Überblick für Dienstleister und Kunden Kostensenkung Vermeidung von Mehrfacharbeit/Mehrfacherfassung Mehr Produktivität in der Hochschule Nur noch eine Anlaufstelle für Kunden (zentrales Helpdesk) Schnellerer Zugang zu webbasierten Diensten und Netzdiensten Betreiber von Diensten sollen von Benutzerverwaltung befreit werden

10 Architektur: Identitätsmanagement führende Systeme Studierendensekr. HIS-SOS Personen Personalabteilung HIS-SVA Personen Bibliothek? user-db Personen RV-NRW DB or file Personen Weitere Quellen Rollenzuweisung? Import DB, Datei, von Hand, Web-Interf. Administration, Provisionierung handling Tivoli Identity Manager RWTH Studierende Mitarbeiter Azubis Einwohner Bibl.-Nutzer RV-NRW Univ Mitarbeiter Provisionierung, automatisch Selbstprovisionierung ev. mit Approval Dienste Campus TSMArchiv HPC others

11 2. Identitätsmanagement des RZ 1. Einführung Ausgangslage, Ziele, Architektur 2. Erfahrungen: Identitätsmanagement des RZ Überblick, Freischaltprozess für Studierende Quellsysteme: Anbindung der HR-Feeds Zielsysteme: Provisionierung neuer Dienste Wandel, Aufwände, Fazit 3. Ausblick: RWTH-Identitätsmanagement Was fehlt noch für die RWTH?.. und über die RWTH hinaus. 4. Zusammenfassung

12 Durch ITIM provisionierte Dienste Produktiv ITIM-Accounts rz. post.}rwth-aachen.de CampusOffice Einwahldienste (Radius, VPN / WLAN, Uni-DSL, DFN@Home) CIP-Pool TSM-Archiv MSDNAA Webspace In Planungs- oder Realisierungsphase Condor / RWTH-Grid IXI / UMS Unix Cluster Dienste in anderen Fachbereichen

13 Verteilung der Accounts ITIM Mops/VPN/Dialup Campus Office MSDNAA Webspace CIP-Pool TSM Archiv 30708

14 Freischaltprozess Freischaltcode (einmal PIN) Versand mit Studienbescheinigung nach Immatrikulation Freischaltung mit Java Web-Appl. in 4 Schritten: 1. Eingabe von Matrikelnummer und Freischaltcode 2. Auswahl einer adresse aus einer Vorschlagsliste und Veröffentlichung ja/nein 3. Bestätigung, dass Angabe korrekt 4. Auslieferung von Username, Passwort, adresse Eintragung in User-Objekt über ITIM-Java-API

15

16

17

18

19

20

21

22

23 2.1 Quellsysteme führende Systeme Studierendensekr. HIS-SOS Personen Personalabteilung HIS-SVA Personen Bibliothek? user-db Personen RV-NRW DB or file Personen Rollenzuweisung? Weitere Quellen Import DB, Datei, von Hand, Web-Interf. Administration, Provisionierung handling Tivoli Identity Manager RWTH Studierende Mitarbeiter Azubis Einwohner Bibl.-Nutzer RV-NRW Univ Mitarbeiter Provisionierung, automatisch Selbstprovisionierung ev. mit Approval Dienste Campus TSMArchiv HPC others

24 Gespeicherte Personenattribute Prinzip So wenig wie möglich So viel wie nötig Konkret Name UID (ohne Semantik), Passwort adresse Anschrift oder Institutszugehörigkeit Verlinkung mit HR-Systemen (SOS, SVA, Alumni, etc)

25 HR-Feed HIS/SOS HTTPs-Fileupload über Browser/Java-Servlet Einfach und sicher firewallfreundlich CSV-Datei mit allen Studierenden (z.z. >30.000) Bis zu 3 mal wöchentlich (je nach Bedarf, Anstoß durch ZHV Dez 7) Enthaltene Informationen: Matrikelnummer Name, Anschrift Freischaltcode (einmal PIN, per Postweg an Stud.)

26 Ablauf des HIS/SOS Abgleiches Bildung der Mengen MH bzw. MT aus den Matrikelnummern in HIS/SOS bzw. ITIM Die Differenzmengen MH-MT und MT-MH liefern die neu immatrikulierten und exmatrikulierten Studierenden MH MT Exmatrikulationen Neueinschreibungen

27 Ablauf des HIS/SOS Abgleiches Abbildung zwischen ITIM u. HIS/SOS über 2 Attribute: Matrikelnummer Statusfeld Für neue Stud. werden neue Identitäten angelegt rwthreplicationcode: SOS; rwthreplicationstatus: SOS;active Exmatrikulierte Stud. werden markiert, Identitäten und Abbildung bleiben erhalten: rwthreplicationcode: SOS; rwthreplicationstatus: SOS;deleted

28 Ablauf des HIS/SOS Abgleiches Programmlauf benötigt unter 4 Minuten, kann also problemlos mehrfach täglich laufen. Vorteile: kurzfristig realisierbar, auch ohne Stagingtabellen etc. Konsistenz der Daten gegenüber Stagingtabellen Weniger Vorbehalte als bei Direktanbindung Bei erneuter Immatrikulation wird die alte Zuordnung wieder hergestellt. Eine Person in ITIM kann mehren Identitäten in führenden Systemen zugeordnet sein

29 Ablauf des HIS/SVA Abgleiches Problematik: hohe Überlappung mit HIS/SOS (Hiwis, Doktoranden) Lösung in ITIM auf Basis des Namensvergleichs kann nicht so gut sein wie eine Lösung an der Quelle, also bei der Einstellung Keine Verteilung von Freischaltcodes/PINs bei der Einstellung Personaldaten sind politisch sensitiv (Personalrat)

30 Ablauf des HIS/SVA Abgleiches (2) Vorläufige Lösung: Übermittlung aller Änderungen in HIS/SVA beschränkt auf: TH-Personalnummer, Name, Institutszugehörigkeit Nutzung der Daten nur bei Vergabe der Rolle Mitarbeiter und zum Entzug dieser Rolle Datenumfang reicht nicht aus um Personen in ITIM anzulegen Datenumfang ist gut genug, um vorhandene Personen zu Mitarbeitern zu machen. Entgültige Lösung: später

31 Ablauf des HIS/SVA Abgleiches (3) Mitarbeiterstatus an vorhandene Person zuweisen: Abbildung zwischen ITIM u. HIS/SVA über Attribute: TH-Empfängernummer Statusfeld Neue Attribute für Person in ITIM: rwthreplicationcode: SVA; rwthreplicationstatus: SVA;active Javaanwendung für Statusänderung mit Parameter: ITIM-UID, Passwort, TH-Empfängernummer

32 2.2 Zielsysteme führende Systeme Studierendensekr. HIS-SOS Personen Personalabteilung HIS-SVA Personen Bibliothek? user-db Personen RV-NRW DB or file Personen Rollenzuweisung? Weitere Quellen Import DB, Datei, von Hand, Web-Interf. Administration, Provisionierung handling Tivoli Identity Manager RWTH Studierende Mitarbeiter Azubis Einwohner Bibl.-Nutzer RV-NRW Univ Mitarbeiter Provisionierung, automatisch Selbstprovisionierung ev. mit Approval Dienste Campus TSMArchiv HPC others

33 Regeln für die Provisionierung Fragen zur Ermittlung von Provisionierungsregeln Welche Parameter werden benötigt Wie werden die Parameter für Accounts gebildet Wer darf Dienste nutzen Wer muss ggf. zustimmen Wer muss ggf. weitere Informationen liefern? Konfiguration in LDAP-Schema und ITIM- Weboberfläche Dienste können stateless oder statefull sein

34 Beispiele Online-Dienste Zweck: VPN, WLAN, Einwahl, UniDSL Nutzung: durch alle Studierenden und Mitarbeiter Parameter: UID, Passwort TSM-Archiv Zweck: Nutzung des Bandroboters Nutzung: durch Mitarbeiter Parameter: IKZ, archivedelete, backupdelete, clientcompression, cn, eraccountstatus, eruid, keepmp, locked, maxnummp, nodetype, tsmdomainmembership, validateprotocol, eraccountcompliance, mail, sn

35 Beispiel Zweck: Nutzung: Mitarbeiter, Studierende, Alumni Parameter: UID, Passwort, Mailadresse, Weiterleitungsadressen, Mailaliases, Maildelivery- Option Weitere Parameter werden im Mailsystem gepflegt: Abwesenheitsnotiz Adressbuch Quotierung Mailfilter

36 Konfiguration der Agenten Agenten führen die Provisionierung in den Zielsystemen per HTTPs/DSML durch: Add Request Delete Request Change Request Reconciliation Agenten für: Windows 2000 Solaris / Unix Universalagent: IBM Directory Integrator (IDI)

37 IBM Directory Integrator (IDI) (fast) universelles Werkzeug zur Konvertierung von Datenbeständen Assemblylines mit einer Vielzahl von Connectoren oder Eventhandlern. Beispiele: LDAP SQL (JDBC) CSV DSML Hooks in Java oder JavaScript Graphische Programmierung

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53 2.3 Erfahrungen 1. Einführung Ausgangslage, Ziele, Architektur 2. Erfahrungen: Identitätsmanagement des RZ Überblick, Freischaltprozess für Studierende Quellsysteme: Anbindung der HR-Feeds Zielsysteme: Provisionierung neuer Dienste Wandel, Aufwände, Fazit 3. Ausblick: RWTH-Identitätsmanagement Was fehlt noch für die RWTH?.. und über die RWTH hinaus. 4. Zusammenfassung

54 Arbeit und Prozesse ändern sich RZ-Mitarbeiter Abgabe von Verantwortung für Provisionierung. Konzentration auf Qualität des Dienste Keine Standardanfragen von Kunden Kunden (Studierende und Mitarbeiter) Standardvorgänge können Online (24x7) erfolgen. Kein Durchfragen zu den für den Dienst zuständigen Mitarbeitern Leichter Zugang zu Hilfe für die meisten Fragen (11 Std./5 Tage) Helpdesk-Personal Vermittler zwischen technischem Personal und Laien. Know How: Prozesse, Virenschutz und Beseitigung, konfiguration, WLAN/VPN

55 Kosten 2 kleine Server Softwarekosten (NRW-Landeslizenz für IBM/Tivoli) Ca. 8 Personentage Serviceleistung für die Pilotinstallation Bislang 1 volle Stelle für 12 Monate Im Mittel eine weitere Stelle wechselnd je nach Projektfortschritt Beteiligung der Diensterbringer in der Migrationsphase Erheblicher Aufwand für ein mittleres Uni-RZ

56 Konsequenz Es geht nicht nebenher Es geht nicht ohne erheblichen eigenen Einsatz Knowhow-Aufbau Internes Wissen ist nicht beim Dienstleister CIO mit Weisungsbefugnis für die beteiligten Stellen oder externer Dienstleister/Moderator ist unabdingbar

57 3. RWTH-Identitätsmanagement 1. Einführung Ausgangslage, Ziele, Architektur 2. Erfahrungen: Identitätsmanagement des RZ Überblick, Freischaltprozess für Studierende Quellsysteme: Anbindung der HR-Feeds Zielsysteme: Provisionierung neuer Dienste Wandel, Aufwände, Fazit 3. Ausblick: RWTH-Identitätsmanagement Was fehlt noch für die RWTH?.. und über die RWTH hinaus. 4. Zusammenfassung

58 3. RWTH Identity Management Projektgruppe RZ zusammen mit der Verwaltung (Federführung) Einbeziehung eines externen Projektpartners In engem Kontakt mit anderen NRW-Hochschulen Projektziele Identity Management für die RWTH lifelong RWTH Kundennummer

59 HR-Feeds auf der TODO-Liste Aktuell: Identifizierung der Mitarbeiter Aktuell: Realisierung der Prozesse für Mitarbeiter Anschließend: Gäste, Gastwissenschaftler (=nicht SVA Mitarbeiter) Alumni (neue und existierende) Stadtnutzer der Bibliothek Klinikmitarbeiter? (SAP)?

60 Was fehlt Saubere Prozesse erfordern saubere Ausgangsdaten Studierende: Abgleich mit HIS/SOS Regelmäßige Information über Abgänge Mitarbeiterdaten: nur aus HIS/SVA, nur geringer Umfang Regelmäßige Information über Abgänge Gäste: individuelle Anmeldung über die Hochschuleinrichtungen Keine Kenntnis über Abgänge Zuständigkeit für mehrfache Gruppenzugehörigkeit?

61 Jenseits der RWTH ITIM organisiert Identitäten in Containern RWTH Studierende und Mitarbeiter in einem Container Es fehlt die klare Trennung Zuordnung zu FB oft willkürlich, nicht eindeutig Aufnahme von Angehörigen anderer Hochschulen in jeweils eigene Container Dezentrale Pflege der Daten Zentrales provisionieren, auch von Diensten außerhalb der RWTH

62 Zusammenfassung und Ausblick ITIM ist seit 7/04 im Produktionsbetrieb > Identitäten, > Accounts 11 provisionierte Dienste erheblicher Investitionsaufwand, 1 Jahr Vorlauf zentralisierte Benutzerverwaltung/Help-Desk reduziert Aufwände bei den Diensten deutlich Manche Dienste werden erst dadurch realisierbar beschleunigt neue Dienste einzuführen (MSDN-AA) Ausweitung auf hochschulweites Identitätsmanagement läuft Kooperation mit NRW-Hochschulen

63 Vielen Dank für Ihre Aufmerksamkeit!