Tivoli Identity Manager 2 Jahre Betriebserfahrung an der RWTH Aachen Guido Bunsen (bunsen@rz.rwth-aachen.de)
Inhalt Zusammenfassung Projektstand Produktauswahl / Implementierungsansatz in Aachen Anbindung der HR-Systeme (HIS) Anbindung der Dienste / Zahlen Automatismen / Provisioning Policies Neue Prozesse Zeitskala
Projektstand Mehr als 50.000 Personenobjekte mit definiertem Status (RWTH-Mitarbeiter, Studierende, UKA-Mitarbeiter, sog. Gäste, Alumni) Grundlage für Authentifizierung und Authorisierung Mehr als 150.000 Accounts (Email, Online-Dienste, etc.) Auswirkungen in vielen Bereichen der RWTH Zentrales Helpdesk Ansprechpartner von früh bis spät Definierter Lifecycle (Immatrikulation/Einstellung, Exmatrikulation/Vertragsende) mit daran gekoppelten Prozessen Schneller Zugang zu Diensten / schneller Entzug von Berechtigungen
Warum Tivoli Identity Manager (TIM)? Eigene Ansätze zur Homogenisierung der Diensteverwaltung Ende 2002 Abschluss eines Tivoli-Landesvertrages (ohne TIM) Anfang 2003 Vorstellung von TIM durch IBM Großes Interesse bei den beteiligten NRW-Hochschulen TIM - Testinstallation in Aachen und Bonn mit Unterstützung von IBM Zu dieser Zeit waren keine technisch gleichwertigen und bezahlbare Lösungen in Sicht TIM (Version 4.5.1) seit Juli 2004 in der RWTH im Produktionsbetrieb NRW-Konsortialbeschaffung mit RWTH als Konsortialführer in Q4 2004 für 10 Hochschulen, damit ist TIM bezahlbar
Konsortialbeschaffung / Vorteile NRW-Konsortialbeschaffung mit RWTH als Konsortialführer in Q4 2004 für 10 Hochschulen AC, BI, BN, DU-E, MS, PB, FH-Bielefeld, FH-Dortmund, FH-Köln, DSHS Köln Ein für Hochschulen bezahlbarer Preis Konsortialvertrag beinhaltet 200 Supporttage Kräfte werden gebündelt, Kooperation der Hochschulen bei Schulung Implementierung Genehmigungsverfahren (Vorabkontrollen nach DSG) Einmaliges Zeitfenster für den Einstieg, gerade für kleine Hochschulen!
Vorläufiger Aachener Ansatz Bottom up weil: Schwerpunkt auf RZ Prozesse insb. Benutzer- und Accountverwaltung weil zunächst reines RZ Projekt Keine Anbindung an alle HR-Feeds, aber dennoch recht gute Abdeckung Relativ schnell brauchbare Ergebnisse gewünscht Zustand der HR-Feeds: Größte Nutzergruppe: Studierende (30.000, 6.000/Jahr): Anbindung vorhanden Mitarbeiter (4.670): Anbindung vorhanden (jedoch keine Übernahme von Identitäten) Gäste, Alumni: Papierprozess Universitätsklinikum Aachen (UKA): wie Mitarbeiter
HIS/ITIM Mapping von Personenobjekten Derzeit noch keine einheitliche ID / Kundennummer, auch weil kein Rückfluss in HR-Systeme Daher Mapping mit Schlüsseln aus den HR-Systemen: aktiver Student RWTHreplicationKey: SOS;100460 RWTHreplicationStatus: SOS;active inaktiver Student RWTHreplicationKey: SOS;100460 RWTHreplicationStatus: SOS;deleted aktiver Mitarbeiter RWTHreplicationKey: SVA;123456 RWTHreplicationStatus: SVA;active
HIS/ITIM Mapping von Personenobjekten Mitarbeiter der mal Student war RWTHreplicationKey: SOS;100460 RWTHreplicationStatus: SOS;deleted RWTHreplicationKey: SVA;123456 RWTHreplicationStatus: SVA;active Analog geht das mit Identitäten in anderen HR-Quellen Alumni, Campus,. Vorteil: keine Schemaerweiterung für Mapping mit weiteren Systemen Besser: einheitliche RWTH-Kundennummer (RWTH-ID) in allen Systemen!?
Abgleich HIS/SOS Attribute: Name, Matrikelnummer, Freischaltcode, Geschlecht, Telefonnummer, Anschrift) Studiengänge Immer klären: Welche Prozesse sollen die Daten wie nutzen!!!! Uploadfrequenz: Nach Bedarf: Oktober 12 mal, Januar 2 mal u.u. abhängig von anderen Prozessen wie z.b. Zahlungseingang Algorithmus (seit Inbetriebnahme) (Java, kein IDI): Sh: Menge aller Matrikelnummern von Studierenden in HIS St: Menge aller Matrikelnummern von Studierenden in ITIM Sh/St, St/Sh, Schnittmenge(Sh,St)
Konsequenzen aus HIS/SOS Abgleich Datenführerschaft des Studierendensekretariates für Studierende: Helpdesk legt keine Studierenden-Objekte neu an Helpdesk kann keine Studierenden-Objekte ändern Ausnahme Freischaltcode neu setzen (aber nicht einsehen) Studierende bekommen PW und Basis Accounts ausschliesslich durch spezielle Web-Anwendung
Abgleich HIS/SVA Austausch von TH-Personalnr., Name, Dienststelle (IKZ) HIS/SVA-Daten nicht zum Anlegen von Personen in TIM, weil: Mitarbeiter sind zum überwiegenden Teil bereits vorhanden Für Abgleich wären relativ viele Informationen erforderlich Geburtsdatum Geburtsort Konsistente Schreibweise in HIS/SOS und HIS/SVA Für Hiwis und Doktoranden sind in HIS/SVA keine Matrikelnummern erfasst
Abgleich HIS/SVA Person macht sich selber zum Mitarbeiter: Anmelden in TIM (Eigene Webanwendung / Servlet) Eingabe der TH-Personalnummer Mapping wird hergestellt wenn Namen in TIM und SVA übereinstimmen und TH-Personalnummer nicht bereits zugewiesen ist Benachrichtigung per Email / Postweg an HIS- u./o. ITIM-Adr. Entzug der Mitarbeiterrolle geschieht automatisch Entzug von Accounts, Rechten und Rollen Analoges Vorgehen beim UKA (eigene Pers.-Abt.)
Anbindung von Diensten mit IDI IBM Directory Integrator ( Datenintegration!) Datenflüsse zwischen Systemen, ausgelöst durch Ereignisse Modelliert Fließband (Assembly Line) Programmierung in graphischer Oberfläche IDI Aktivitäten entlang einer Assembly Line: Reagiert auf Ereignisse (EventHandler) Holt Daten aus verschiedenen Systemen (Connector) Startet passende Datenflüsse (AssemblyLine) Wandelt Daten ggf. geeignet um (Parser) Erlaubt einfache 1:1 Datenumwandlung Ermöglicht komplexe Datenumwandlung durch Skriptsprachen Liefert Daten in verschiedenen Systemen ab (Connector)
Bislang angeschlossene Dienste Anbindung einer Vielzahl von Diensten: Email (@rwth, @post, @rz ) Online-Dienste (WLAN, VPN, Einwahl) Windows CIP-Pool bzw. Hausnetz WWW für persönliche Webseiten MSDN AA TSM-Archiv-Dienst NRW Grid CampusOffice (Dahinter auch vzpa und Alcatel/Nextira One- Telefonanlage) HPC-Cluster TIM
158432 Provisionierte Accounts (Okt. 05) Provisionierte Accounts (158432) 2123 225 1123 38050 37788 99 24522 44895 3223 6384 Email WWW MSDN-AA CampusOffice TSM-Archiv Online Unix UMS CIP TIM
Provisioning Policies / TIM Workflow Anlegen von Accountgrundausstattung für die Studierenden durch Automatismen in TIM Email, Einwahldienste, CampusOffice, TIM Approvalprozesse bzw. Request for Information bei UMS, TSM-Archiv Automatischer Entzug von Accounts bei Exmatrikulation: CampusOffice, MSDN AA Start des Lifecycle -Prozesses Selbstbedienung: TSM-Archiv, UMS, MSDN AA, HPC-Cluster (Unix)
Lifecycle Prozess Zustand Start Wait 2 Die Problemstellung: Ergebnis: Emails enthalten einen personalisierten Email Weblink Richtlinien Was soll die passieren TOauf der wenn eine FB/TO Zugehörigkeit Person exmatrikuliert zur Hochschule wird basieren oder wenn werden ein weitesgehend Dienstvertrag Die Webanwendung ev. DEL Email erlaubt bei ohne endet? Teilnahme von RZ-Personal gegebenen Voraussetzungen die eingehalten Statusänderung. Wait 1 End FB ev. DEL Bedingung Aktion Timeout Feedback Emailversand Del Accounts
Konsequenzen: Zentrales Helpdesk Vorher: Mitarbeiter betreuen ihre Kunden selber Jetzt: Zentrale Anlaufstelle für Studierende und Mitarbeiter Allgemeine Fragen PW-Vergessen Neueintrag in TIM Konfiguration und Nutzung von Email, VPN, Anti-Viren-Softw. 8:00 bis 19:00 / Unabhängig von Verfügbarkeit der RZ- Mitarbeiter Zugang telefonisch (80-24680), per Email oder persönlich Unterstützung einfacher Problemlösungsprozesse durch Callmanager Software Auditing in TIM (wer, was, wann)
Konsequenzen: Accountvergabe Weniger vergebene Accounts Persönliche Webseiten nur noch bei Bedarf Mehr Wissen über die Eigentümer der Accounts Adopten von mehr als 700 Emailaccounts Automatischer Entzug von Accounts CampusOffice, CIP-Pool Demnächst z.b. auch bei Online Diensten Accounts nur bei rechtlicher Voraussetzungen MSDN AA Schnelle Integration neuer Dienste MSDN AA IXI/UMS
Konsequenzen: Dienstanbieter Entlastung von Routineaufgaben Konzentration auf Kernkompetenz und echte Probleme weniger Sozialkontakte? Es entstehen aber auch Unsicherheiten Neue Abhängigkeiten entstehen Wird das zuverlässig funktionieren? Prozesse müssen genau definiert werden Aufspaltung in Teilprozesse (Person anlegen, Accountanlegen)
Beteiligte Personengruppen Dienstanbieter Kunden
Beteiligte Personengruppen Dienstanbieter Helpdesk Kunden TIM Admins
Was hätten wir lieber anders Bessere Benutzerführung, mehr Anpassungsmöglichkeiten in der Weboberfläche Mehr Barrierefreiheit Unterstützung von zusätzlichen Browser Mehr Performance bei Policyänderungen (Problem in AC) Prozesse in der Hochschulverwaltung müssen überarbeitet werden / HIS-Anwendungen müssen sich mehr öffnen Mehrsprachigkeit wurde von uns bislang nicht getestet Anbindung der Bibliothek Direktere Anbindung der HIS-Datenquellen
Was besser geworden ist notwendigerweise werden jetzt alle Prozesse genauer spezifiziert Dadurch ist alles wesentlich strukturierter Die Qualität der Datenbestände ist deutlich verbessert (aber leider immer noch nicht gut genug) Die Zusammenarbeit im Haus und der RWTH ist intensiver Die Wartbarkeit ist deutlich verbessert
Ein langer Weg 2002 Produktvorstellung in Bommerholz 2003 Februar/März: TIM Schulung in AC / Workshop in BN 2003 Mai: Testinstallation in Aachen 2003 September: Mitarbeiterin nur für TIM 2003 Oktober: Verfügbarkeit von TIM 4.5 (IDI) 2003 Dezember: Eigene Neuinstallation 2004 Februar: Installation auf neu beschafftem Prod.-System 2004 März/April: Migrationstests, Agents 2004 Juli: Produktionsbetrieb 2004 ab Sommer: Ausweitung auf andere Dienste, Unterstützung weiterer Prozesse 2005 Implementierung Lifecycle / Aufräumen 2006 SSO für Webanwendungen / Shibboleth