identity management an der universität stuttgart · • homogene struktur ... ausbau, neue...

Technische Informations- und

Kommunikationsdienste (TIK)

Thomas Wolfram

Identity Managementan der

Universität Stuttgart

ZKI-Arbeitskreis VerzeichnisdiensteFrühjahrstreffen 2018

Agenda

• Universität Stuttgart – Überblick

• IT-Landschaft der Universität Stuttgart aus Sicht des IdM

• Historie

• SIAM – Stuttgarter Identity und Access Management

• (Fokus auf IdM)

• Fazit und Ausblick


• 28.000 Studierende

• 16,6 % Bildungsausländer

• 5.300 Mitarbeiter

• 2.200 Hiwis

• 10 Fakultäten

• 180 Institute

• 265 Prof.

• Zwei Standorte

• Campus Stadtmitte

• Campus Vaihingen

Überblick



IT-Landschaft an der Universität Stuttgartaus Sicht des IdM

Identity Management an der


22.03.2018Universität Stuttgart, TIK 4

Organisationen und Dienste

• Zentrale IT-Infrastruktur und –Dienste durch TIK …

• Netz, IAM, Storage, Mail, VoIP, Web, DBs, E-Learning, ZV-Fachanwendungen usw.

• … für dezentrale Organisationsstrukturen in Fakultäten und Forschungseinrichtungen

• Heterogene IT-Strukturen in unterschiedlicher Breite/Tiefe an Instituten

• Relativ eigenständige IT, … Teilnutzung von TIK-Diensten, … bis vollständig vom TIK betreute IT

• Beispiel: E-Mail

• Zentraler E-Maildienst des TIK (Exchange): ca. 65% der Nutzer in ca. 280 Maildomains

• Parallel ca. 50 dezentrale Mailserver: ca. 35% der Nutzer in ca. 85 Maildomains

• ABER: Trend zur Rückmigration zu TIK-Diensten in den letzten Jahren

• … für Studierende, Zentrale Verwaltung (ZV) und Einrichtungen

• Homogene Struktur

• Vollständig vom TIK betreute, zentrale IT-Dienste großer Tiefe


Personengruppen / Nutzerkategorien

• Viele unterschiedliche Personengruppen

• Mitglieder und Angehörige nach LHG

• Externe / „Weitere“

• Mehrere Quellen für Stammdaten für unterschiedliche Personengruppen

• Problem der Zuordnung

• Wer darf / bekommt / sieht was?

• Datenschutz




Historie




Anfänge

• 2004 – Projekt Erreichbarkeitsverzeichnis (EVE)

• Einführung „MetaHub“: automatisierter Datenaustausch mit der ZV

• Eigenentwicklung, Java EE basierte Middleware, Teilfunktionen eines ESB

• 2005 – Evaluation IDM-Systeme

• Ergebnis: Sun Identity Manager

• Aber keine Einführung

• 2007 – Projekt UniAdmin

• Dezentrale Administration für EVE durch ernannte Beauftragte in den Instituten und

Einrichtungen (Delegierung)

• 2008 – Beginn Projekt eBologna (Einführung HIS LSF)

• Testbetrieb Sun IDM im Kontext Bologna-Prozess

• Einführung neuer einheitlicher Benutzerkonten


Einführung IdM

• 2009 – Beginn Projekt SIAM mit 3 Jahren Laufzeit, 3 zusätzliche wiss. Projektmitarbeiter

• Beginn der schrittweisen Einführung Sun IDM

• Entwicklung Basis-Datenmodell und -Rollenmodell für SIAM, Prozessdefinitionen

• Entwicklung Datenmodell + Applikation für Aufbau-Organigramm für Universität

• Stammdatenübernahme aus HIS SVA, HIS SOS

• Anbindung / Konsolidierung der wichtigsten zentralen Zielsysteme (insb. Access Management)


• Lizensierung Sun Identity Manager

• Erwartungshaltung: Sun IDM Landeslizenz für BW über MWK kommt

• Sun erlaubt Betrieb auf Basis freier Runtime-Lizenz im Kontext Open Source Strategie

• Support: Pre-Sales-Support von Sun, Berater, Sun-Community-Support

• April: Oracle kündigt Übernahme von Sun Microsystems an, EU-Genehmigung unklar

• November: EU-Kommission sieht (zunächst) wettbewerbsrechtliche Probleme

Einführung IdM (2)

• 2010 – Weiterer Ausbau SIAM, Konsolidierung Nutzerverwaltungen usw.

• Januar: EU-Kommission genehmigt Sun-Übernahme durch Oracle

• Zwischenzeitlich erste Phase SIAM inklusive Sun IDM erfolgreich produktiv


• Sun IDM wird Oracle Waveset und gleichzeitig abgekündigt mit (damals) EOL in 2014

• Zusage Support, Security-Updates, Bug-Fixes und beschränkte Weiterentwicklung bis EOL

• Zusage Migrationsunterstützung auf Oracle Identity Manager (OIM) wird angekündigt

• Keine Übernahme der Open Source Strategie von Sun

• Weiterbetrieb der letzten Sun-Version zulässig, Upgrades nur für lizensierte Oracle-Kunden

• Landeslizenz BW über MWK kommt nicht

• Kurz- bis mittelfristiger Wechsel auf anderes IdM-System unrealistisch

• Eintritt in Verhandlungen mit Oracle / Temporäre Lizenz (d.h. Zugang zu Updates / Upgrades)

• Ziel: Produktiven Betrieb mit Waveset bis min. 2014 sichern, langfristige Migration auf OIM

Einführung IdM (3)

• 2011 – Projektabschluss SIAM, Überführung in Dienst SIAM

• Weitere Integration, Aufbau Gästeverwaltung, weitere Konsolidierungen, …

• Projektstellen laufen aus


• Nach Verhandlungen Lizensierung von Oracle Waveset

• Option für 1:1 Lizenzumtausch auf OIM

• Langfristige Überlegungen:

• Eindruck von OIM: Betrieb im Uni-Umfeld schwierig (IdM an der Uni = „Moving Target“)

• Sehr mächtig, aber eher „schwergewichtig“, steile Lernkurve

• Migrationssupport von Waveset auf OIM bis dahin unzureichend bzw. nicht existent

• Entweder mehr Personal oder externer Dienstleister

• Suche nach Alternativen beginnt

• Novell / NetIQ, FIM, OpenIDM (frühe Version)

Ausbau, neue Anforderungen / Zielsysteme

• 2012 – Beginn (technisch) Campus Management Projekt, Teilprojekt CUS-IdM

• Beginn Reduzierung Abhängigkeiten von Waveset (Geschäftslogik, XPRESS-Code)

• Beginn Ablösung von HIS SOS/POS/ZUL/LSF durch C@MPUS (Campus Online)

• Entwicklung Anbindung C@MPUS an SIAM

• Übernahme Stammdaten, Studiengänge / Prov. Accounts, Mitarbeiter, Chipkartendaten

• Umstellung von Zugangsdatenbrief auf Aktivierungsverfahren für studentische Accounts

• 2013 – Einführung neue Groupware (Zarafa), Fortsetzung CUS-IdM

• Ablösung für Communigate Pro (Mitarbeiter) und iMail (Studierende)

• Integration ins IdM, Umstellung aller Studierenden


• Oracle verlängert weiter Waveset-Support über 2014 hinaus

• 2014 – Abschluss CUS-IdM, Inbetriebnahme C@MPUS-Anbindung, Zarafa-Migration

• Umstellung von ca. 50% Beschäftigten- und Funktionskonten auf Zarafa

• Anbindung weiterer Systeme (CIP-Pools, UB, Kaba, SWS)

Weiterentwicklung / Wechsel IdM-System

• 2015 – Beginn Exchange Projekt

• Januar: Zarafa kündigt plötzlich Outlook-Support ab

• Mai: Beschluss: Abbruch des Zarafa-Projekts, Wechsel zu on-prem. Exchange

• Auswahl- und Vergabeverfahren für einen Dienstleister

• Problem für SIAM: absehbarer Parallelbetrieb von 2 bzw. später 3 Mailsystemen

• Durch Org-spezifische Maildomains z.T. komplexe Prozesse bei Wechseln innerhalb der Uni

• Z.B. Rückmigrationen bei Wechseln von „Zarafa“- in „CGPro“-Institute

• Erhebliche Anpassungen im IdM erforderlich

• Provisionierung Exchange 2016 mit Waveset nicht supported / problematisch

• 2016 – Evaluierung / Tests mit ForgeRock OpenIDM

• Design-Workshops Exchange mit Dienstleister

• OpenIDM „Proof of Concept“ für Exchange-Provisionierung

• Online-Schulungen


Weiterentwicklung / Wechsel IdM-System (2)

• 2017 – Migration auf Exchange, Migration auf OpenIDM

• Koordination der Mailbox-Migrationen, Provisionierungen über Zustandsautomat in

SIAM bzw. OpenIDM


• Lizensierung ForgeRock OpenIDM

• Eintritt in Verhandlungen mit ForgeRock / Temporäre Lizenz mit Support

• September: Bundesweite Ausschreibung, Leistungsverzeichnis

• Dezember: Auswahl eines ForgeRock-Partners, Subscription ab 01.01.2017

• November: OpenIDM geht produktiv, stark getrieben durch Exchange-Projekt

• Parallelbetrieb beider IdMs, zunächst (fast) völlig getrennt

• OpenIDM nur für Exchange (Getrenntes Service-AD für Exchange)

• Workarounds für übergreifende Synchronisationen

Weiterentwicklung / Wechsel IdM-System (3)

• Weitere IdM-Anpassungen für zeitweisen Parallelbetrieb von 4 Mailsystemen

• Zarafa, CGPro Oracle Waveset

• Exchange, Mailrelay-Gruppen ForgeRock OpenIDM

• Migration der Zarafa-Konten (bis Mai) und der CGPro-Konten (bis Dezember)

• Erweiterungen im UniAdmin und Self-Service

• Problem: Parallelbetrieb zweier IdMs in getrennten „Inseln“

• Übergreifende Synchronisation Account-Zustände, Attribut- und Passwortänderungen,

übergreifende Workflows (z.B. Aktivierungen, Löschungen, Reconciliation) aufwändig

• „Big Bang“-Umstellung nicht praktikabel bzw. realistisch

• Zu viele Abhängigkeiten

• „Kopplung“: OpenIDM zentrale Engine

• Logische „Nachordnung“ von Waveset unter OpenIDM

• Schrittweises Umstellen der Zielsysteme von Waveset auf OpenIDM




Stuttgarter Identity und Access Management



16

Überblick

• Zentrales Identity und Access Management (IAM) für die Universität Stuttgart

• Ursprünglich eingeführt im Rahmen eines Projektes

• Projektlaufzeit 01.01.2009 – 31.12.2011

• 2 feste Mitarbeiter + 3 Projekt-Mitarbeiter

• Lenkungsgremium: Prorektor Struktur, Kanzlerin, RUS-Leitung (RUS = heute TIK)

• Zweck: Abbildung des Lebenszyklus der digitalen Identitäten in den zentralen IT-

Systemen vom Eintritt bis zum Ausscheiden aus der Universität

• Einheitliche, automatisch generierte und verwaltete Nutzerkennungen und

Zugangsberechtigungen zu zentralen IT-Diensten

• Tagesaktuell basierend auf Stammdaten für alle relevanten Personengruppen

• Ca. 63.000 aktive IdM-verwaltete Nutzerkonten aller Typen

• Studierenden-, Mitarbeiter-, Gast-, Partner-, Admin-, Funktions- und System-/Servicekonten

Stuttgarter Identity- und Accessmanagement

Überblick (2)

• Weitere Ergebnisse

• Konsolidierung Stammdaten und Ablösung alter Nutzerverwaltungen

• Zuordnung existierender Alt-Nutzerkonten zu besitzenden Identitäten

• Schrittweise Ablösung der bisherigen Benutzer- und Rechteverwaltungen

• Einheitliche, automatisierte Provisionierungsprozesse für zentrale Systeme

• Zentrales Datenmodell für (möglichst) alle Identitäten, sowie Aufbau-Organigramm

• Einführung SIAM-ID und Org-ID Übernahme nach C@MPUS

• Zentrales Rollenmodell für TIK-Dienste

• Verbesserung Datenschutz und Sicherheit (Datensparsamkeit, Auditing)

• Self-Servicefunktionen

• Dezentrale Administrationsfunktionen (UniAdmin)

• Personalisierte Portale, SSO, Föderationen (Shibboleth / DFN-AAI / bwIdm)

Stuttgarter Identity- und Accessmanagement

Infrastruktur

• Zentrales Identity Management

• ForgeRock IDM

• Enterprise-Edition von OpenIDM

• (Seit 11/2016 Trennung von Open Source und kommerziellen Editions)

• Oracle Waveset (in Ablösung)

• Vormaliger Sun IDM

• Zentrales Access Management

• Microsoft Active Directory

• 3 Forests mit insgesamt 5 Subdomains

• Shibboleth

• OpenLDAP

• Radiator


Basisdatenmodell


Wichtigste Identifikatoren

• SIAM-ID

• Campusweiter eindeutiger, unveränderlicher Identifikator für Entitäten

• Format: Universally Unique Identifier (UUID) [ITU-T Rec. X.667]

• Vorzeichenlose 128 Bit Zahl die dezentral konfliktfrei generierbar ist

• Z.B. in SIAM bzw. IdM (Mitarbeiter, Gäste), in C@MPUS (Studierende)

• Großer Wertvorrat (dauerhaft / keine Wiederverwendung)

• Als Primärschlüssel für relationale Datenmodelle geeignet, nicht „sprechend“

• SIAM-Account-ID

• Campusweiter unveränderlicher Identifikator (UUID) für Nutzerkonten

• Entitäten besitzen ein oder mehrere Konten

• SIAM-Org-ID

• Campusweiter Identifikator (Int32) für Organisationen

• Aufbau-Organigramm, Studiengänge aus C@MPUS werden in SIAM auf OrgIds gemappt


Personengruppen

• In 2010 Verabschiedung der Liste der:

• „Mitglieder und Angehörige der Universität Stuttgart und weiteren relevanten

Personengruppen im Kontext der Universität"

• 39 Personengruppen

• Hauptkategorien

• Mitglieder der Universität (LHG)

• Angehörige der Universität (LHG, Grundordnung)

• Weitere Personengruppen

• Z.T. Problem keiner führenden Datenquellen, z.B. „studierendenähnliche“ Personen

• Mapping (teilweise) in SIAM auf Org-Affiliations

• orgAffiliationTypeId

• Siehe Basisdatenmodell


Generisches Rollenmodell

• Generische Geschäftsrollen, immer Zuordnung zu Account und Organisation


• Basisattribute:

• Role-ID, SIAM-Account-ID,

Org-ID, ValidFrom, ValidTill

• Vererbung im Organisations-

baum nach unten möglich

• Werden über IdM je nach Zielsystem in Rechte gemappt, ggf. indirekt über Basisrollen

• Z.B. in den ADs in Gruppenmitgliedschaften, in REST-Daten-APIs in Datenfilter

• Rollen beliebig (Absprache), Mapping im IdM oder ggf. im Zielsystem durch Kunden

• Z.B. Administratorrollen, Nutzerrollen, Applikationsrollen (z.B. FIS, CERT)

• Implizite Rollen

• Z.B. Organisations-Leiter aus Organigramm

• „Meta-Rollen“: wie normale Rollen die aber Rechte zur Rollenvergabe festlegen

Logische Datenflüsse


SVA

C@MPUS

SIAM

SmartLife

ForgeRock IDM

+

Oracle Waveset

UniStruktur

ZV-Arbeits-

plätze

UB

Kaba

SSB

SWS

NetApp

UniAdmin

Mailman

OpenCMS

Exchange

IPAM

ILIAS

Radiator

Shibboleth

Arbeits-

plätze

Service AD

Quellsysteme Identity Management Access Management und Zielsysteme

ZV AD

USADR

Kopplung Waveset an OpenIDM während Migration(konzeptionell)


„Proxy“-DB

IDM

ZV-Arbeits-

plätze

Exchange

…weitere…

ILIAS

Arbeits-

plätze

Service AD

ZV AD

USADR

Waveset

SPML

LiveSync

REST

…weitere…

…weitere…

ActiveSync

„Fassade“

ForgeRock IDM

• Modulares Framework, Java / OSGi

• Apache Felix, TIK: Linux VMs

• Jetty Servlet Container

• Docker-Support ab 5.5

• Durchgängige REST-APIs

• JavaScript, Groovy

• Repository

• JDBC für Produktion, TIK: MS SQL

• Flexibles Objektmodell

• BPMNv2 Workflow-Engine

• Activiti

• Connector Framework

• OpenICF


Übersicht Architektur

ForgeRock IDM

• Konzepte z.T. ähnlich Waveset

• Kein Metadirectory

• Aber Synchronisation mit und ohne Attributspeicherung in

zentralen „Managed Objects“ möglich

• OpenDJ als Repo ab 5.5 (nur Dev)

• Leichterer Einstieg als Waveset

• Umfangreiche freie Doku, viele Samples, Schulungen

• Scriptsprachen: JavaScript, Groovy

• ABER: keine IDE-basierten Projekte

• Standard-Workflows (BPMNv2)

• Gute Erweiterungsmöglichkeiten

• Flexibleres Objektmodell, nicht nur Userobjekte

• Repo kann auf eigenes Schema gemappt werden

• Bislang stabiler Betrieb, Support / Beratung zeitnah

• Allerdings (fast) noch keine gravierenden Probleme


Warum und Erfahrungen soweit



Ausblick und Fazit



28

Ausblick

• Abschluss der Migration auf OpenIDM

• Unterstützung Migrationen von Institutsmailservern auf Exchange

• Umbau SVA-Transfer

• Konsolidierung USADR-AD mit ZV-AD

• Ausbau UniAdmin-Portal, Self-Service

• Exchange

• Genehmigungsworkflows

• Neue Anbindungen / Umbau von Anbindungen

• ARENA 2036

• UB

• Weitere 30.000 Walk-in User

• IP-Telefonie

Fazit

• IdM ist etablierter Basisdienst

• „Kommt aus der Steckdose“

• IdM ist nie „fertig“

• Ständig neue Anforderungen

• Oft im Kontext neuer IT-Projekte, die angebunden werden müssen

• Nicht immer frühe Beteiligung

• Z.T. Beschaffungen von „IT-Silos“ in der Vergangenheit

• Aufwand wird oft unterschätzt und/oder nicht voll verstanden

• Sicht aus „10.000m Höhe“ / „Kann doch nicht so schwer sein“

• Allerdings durch zunehmendes Bewusstsein Besserung der Situation

• Unterbrechungsfreie Migration auf ein neues IdM-System komplex

• „Wechsel der Flügel und Triebwerke im Flug“

Vielen Dank!

E-Mail:

Tel.: +49 (0) 711 685-

Web:




Allmandring 30A

70550 Stuttgart

Thomas Wolfram

65812

www.tik.uni-stuttgart.de

Technische Informations- und Kommunikationsdienste (TIK)

[email protected]

identity management an der universität stuttgart · • homogene struktur ... ausbau, neue...

Documents