Identity Management für die Max-Planck-Institute

1. Identity Management für die Max-Planck-Institute Andreas Ißleiber (GWDG) andreas.issleiber@gwdg.de 0551/201-1815

2. Inhalt • Ziele eines Identity Managements • Eckdaten des IdM der GWDG • Angebundene Verzeichnisse • Bausteine des IdM der GWDG • MPG-weites Verzeichnis • Anbindung von Max-Planck-Instituten • Zwei Modelle der Anbindung • Ablaufbeispiel: Anlage eines Benutzers • Ausblick, Fazit

3. Ziele eines/des Identity Managements • Aggregierung von existierenden Identitäten und Accounts • Die Schaffung von Konvergenz in den Bereichen Verzeichnisdienste und Benutzerkonten • Abbildung und Konsolidierung von Prozessen für die Benutzeranlage und Deprovisionierung • Regelung von Zugriffsrechten in den angebundenen Verzeichnissen • Abbildung von Rollen und Gruppen in den Zielverzeichnissen • Aufbau eines föderativen zentralen Verzeichnisses der Max-Planck • Nutzung zentraler Max-Planck Dienste über das IdM

4. Eckdaten des IdM bei der GWDG

5. Eckdaten des IdM bei der GWDG • Einführung des IdM im Juni 2005, mit der Anbindung lokaler Verzeichnisse der GWDG (Windows AD, LDAP) sowie Verzeichnisse der Studierenden (2006)Max-Planck Institute in Göttingen (2008) • Derzeit insgesamt ca. 90.000 Identitäten und 41 angebundener Verzeichnisse/Verzeichnisdienste

6. Eckdaten des IdM bei der GWDG • Produkt: Novell/NetIQ Identity Manager 4.02 (incl. eDirectory) • Kommunikation, sowie Programmierung  XML (DirXML) • Ereignisse/Modifikationen ca. 10.000 – 280.000 / Tag • Angebundene Systeme: • Windows AD (2003-2012) • LDAP • SQL-Datenbanken (PostgreSQL, MySQL, Informix) • Webschnittstellen (Soap) • SAP • Command-Schnittstellen: Shell Scripts, PowerShell (Windows) • Konnektoren für viele weitere Systeme bereits vorhanden • In Größe und Umfang größter Verzeichnisdienst im Bereich der Wissenschaft/Forschung in Niedersachsen

7. Angebundene Verzeichnisse am IdM

8. Angebundene Verzeichnisse am IdM Legende Datenquelle Datensenke Diverse Max-Planck-InstituteWindows AD, LDAP, db Klinikum (UMG)der Universität Diverse Universitäts-Institute Windows ADder GWDG Windows Exchange der GWDG MetaDirectory (Identity Vault) LDAP der GWDG SAP der Universität Sudierende (FlexNow) Diverse Prozesse und Scripts Sudierende (HIS) IdM-Portal Benutzer-Portal In 2011: Einführung der Mandantentrennung (Max-Planck/Universität) im IdMTrennung der Bereiche in unterschiedliche Partitionen

9. Bausteine des IdM der GWDG(Technische Zusammenhänge)

10. Bausteine des IdMbei der GWDG Entwicklungsumgebung Zentrale Authentifizierung MetaDirectory Periphäre Systeme Zentrale Authentifizierung

11. Das MetaDirectory MetaDirectory 1 idm2 MetaDir idm1 MetaDir • MetaDirectory als Basis (zentraler Verzeichnisdienst) • Vollständig redundante Auslegung des Verzeichnisdienstes (eDirectory) (durch zwei Server: idm1 & idm2) eDirectoryReplica-Ring • Read/Write-Replica • IdM-Driver (failover) • Master-Replica • MetaDirectory • Main Server • IdM-Driver • Management ProductiveeDirectory • Idm1 & idm2 laufen in der Servervirtualisierung (vmWare)  Vorteile: Failover, verteilte Standorte, Lastverteilung, Snapshots • Permanente Replikation zwischen Master Replica(idm1) read/writeReplica (idm2) • Alle Verzeichnisse sind an idm1/idm2 direkt über Remote-Loader angebunden • Auf idm1 läuft die „Logik“ sämtlicher Prozesse in Form von Treibern

12. PeriphäreIdM-Systeme Periphäre Systeme 2 Reporting&Monitoring IdM PortalWeb-Portal • Idm-portal • http://idm.gwdg.de • Selfservice (Passwortänderungen etc.) • Administration für die Kunden • Anlage, Modifikation der Benutzer • Eigene Arbeitsumgebung für jeden Kunden • Monitoring • Reporting • Logging • http://idm.gwdg.de • SelfService • Managing Subversion Server Syslog Server • Logging • Tracing • SVN • Monitoring,Reporting-Server • Überwachung der Treiber und Prozesse • Automatisierte Warnungen bei kritischen Zuständen • Bildung von Statistiken & Reports • Logging-Server • Erzeugung von Logfiles der wesentlichen Treiber/Prozesse • Tracefiles der Treiber • Syslog • Subversion • SVN Server zur Versionskontrolle bei der Treiberentwicklung • Möglichkeit zu älteren Treiberversionen zurück zu kehren

13. Entwicklungsumgebung Entwicklungsumgebung 3 Idm2 (devel) MetaDir Idm1 (devel) MetaDir • IdM-Entwicklungsumgebunggetrennt/isoliertvom Produktivsystem • Read/Write-Replica • Master-Replica • Driver Developing • Testing SAPDeveloping • Master-Replica • SAP IdMDeveloping DevelopmenteDirectory • Eigenschaften der Entwicklungsumgebung: • Realistische Arbeitsumgebung (>= 90.000 User) • Treiberentwicklung • Testläufe/Last-Tests z.B. vor Produktivsetzung im Realsystem • Bulkchange • Manipulationen am eDirectory • Test von Software Update/Upgrades • SAP-Treiber Entwicklung • Getrennter Bereich für die Entwicklung der Anbindung von SAP am IdM

14. DisasterRecovery/Backup Disaster-Recovery 4 • Backup-System • Tägliche exakte Kopie des Produktivsystem • Recovery innerhalb von ca. 1-2 Stunden • Events während der offline-phase gehen nicht verloren (RemoteLoader) Idm2.backup MetaDir Idm1.backup MetaDir • Read/Write-Replica(offline) • Master-Replica • IdM-Driver (offline) • IdM Management TSM Backup BackupeDirectory • GWDG Backupsystem • Daten-Backup • Tägliches Voll-Backup des eDirectory zum TSM Server der GWDG • Zusätzliches Backup des eDirectory auf zwei weiteren IdM Server • eDirectory Backup History 20 Tage • Zusätzliches LDIF Backup der Identitäten/Attribute (20 Tage History) • Backupdaten liegen auf örtlich getrennten Systemen

15. Authentifizierungsserver Authentifizierung 5 GWDG Authentication Servers • Zentrale Authentifizierungssysteme • Windows AD der GWDG • LDAP der GWDG • RADIUS Server der GWDG LDAP RADIUS Windows AD Services • Zugang zu zentralen Diensten der GWDG über … • Windows AD der GWDG • LDAP der GWDG • RADIUS Server der GWDG Zentrale Diensteder GWDG

16. Umsetzung eines MPG-weiten föderativen Verzeichnisses

17. Umsetzung des Ergebnis des MPG-IT-Verantwortlichen Treffen 4/2013 in Gera • Bestandteile der Anbindung: • Anbindung an das zentrale IdM der GWDG und damit Integration in ein gemeinsames MPG Verzeichnis • Gemeinsame Dokumentation der Anbindung an das IdM, zusammen mit dem Institut • Standardisierung der Anbindung

18. Optionale Dienstleistung der GWDG: IdMas a Service • Bestandteile von IdMas a Service: • Analyse der lokalen Verzeichnisdienste sowie der Benutzerverwaltung und ggf. Vorschläge zur deren Optimierung • Abbildung der lokalen Prozesse des Instituts im Rahmen der IdM Anbindung • Gemeinsame Dokumentation der Prozesse bei der Anbindung an das IdM, mit dem Institut • Standardisierung und Optimierung von Prozessabläufen • Anbindung etwaiger weiterer Verzeichnisse im Institut (LDAP etc.)

19. Vorteile für das Institut • Keine manuellen Benutzeranträge für jede Account bei der GWDG erforderlich(Problem  vergessene Deprovisionierung) • Nutzung von zentralen Diensten der Max-Planck (MPG-weites Verzeichnis)Diensteanbieter aus der MPG können das Verzeichnis nutzen • Die Autonomie der Benutzerverwaltung bleibt auf Seiten des Instituts • Harmonisierung der UID im zentralen Verzeichnis • Nutzung von zentralen Diensten, basierend auf der Anbindung an das IdM (Eduroam, Sharepoint, Exchange, Cloudshare Dienste) • Optional (IdMas a Service): • Entlastung der lokalen Benutzerverwaltung des Institut • Nutzung des zentralen Web-Portals (http://idm.gwdg.de) zur Administration von Gruppen und Accounts

20. Anbindung von Max-Planck Instituten am IdM der GWDG

21. Anbindung eines Instituts an das IdM • Voraussetzung auf Seiten des Instituts (Institut) • Bevorzugt Windows AD (2003,2008R2,2012) oder alternativ LDAP als lokaler Verzeichnisdienst im Institut • Hierfür existieren bei der GWDG einsatzfähige Templates als Treiber, bei diesen lediglich die Umgebungsparameter definiert werden müssen • Netzzugang (durch Instituts-Firewall) für TCP-Port 8090 • RemoteLoader (GWDG/Institut) • Client-Software (Java), welche alle Änderungen im Verzeichniserkennt und die Daten, wenn erforderlich, zum IdMüberträgt • Der RemoteLoader wird als Dienst auf dem lokalen Server (Verzeichnisdienst)des Instituts Installiert und sichert die Kommunikation zum IdM • Gemeinsame Beantwortung unseres Fragenkataloges (GWDG/Institut) • Die GWDG hat ein Fragenkatalog ausgearbeitet, in welchem die Umgebungsparameter des lokalen Verzeichnisses definiert werden • Dieser Fragenkatalog kann gemeinsam mit der GWDG ausgefüllt werden

22. Anbindung eines Instituts an das IdM • Ausschnitt aus dem Fragenkatalog • Welche Benutzer/Gruppen sollen berücksichtigt werden • Welche Dienste sollen mit der Anbindung an das IdM genutzt werden ? • Welche Attribute sollen (ggf. zusätzlich) berücksichtigt werden • Welche Benutzer/Administratoren sollen vom IdM über den Zustandautomatisch informiert werden (eMail) • Programmierung/Anpassung des Treibers und Dokumentation (GWDG) • Basierend auf dem Fragenkatalog wird der Treiber installiert/angepasst • Gleichzeitig wird mir der Dokumentation der Anbindung begonnen • Installation des Treibers in der IdM Testumgebung • Zunächst wird der Treiber und die Anbindung in der IdM-Testumgebung hinreichend geprüft • Die Netzwerkanbindung wird geprüft (Firewall-Einstellungen des Instituts) • Hierbei werden auch Produktivdaten aus dem Quellverzeichnis importiert (Synchronisation)

23. Anbindung eines Instituts an das IdM • Einrichten der Arbeitsumgebung am IdM-Portal • Für die Administratoren des Instituts wird die Arbeitsumgebung den Wünschen des Instituts entsprechend eingerichtet • Produktivsetzung der Anbindung am MetaDirectory der GWDG (idm1) • Der Treiber wird von der Entwicklungs- und Test-Umgebung in die Produktivumgebung migriert • Initiale Synchronisation der Quellverzeichnisses (bereits gesetzte Passwörter können hierbei nicht synchronisiert werden) • Während der Startphase erhöhtes Monitoring in der Produktivumgebungfür die Anbindung

24. Technische Anbindung eines Instituts MPI-Institut Verzeichnisdienstdes Instituts MetaDirectory GWDGFirewall Firewall (TCP:8090) IdMServer Internet Verschlüsselte Verbindung IdM-Treiber Remote loader • RemoteLoader • Client-Software (Java), welche die Ereignisse im Verzeichniserkennt und die Daten (Änderungen) zum IdM überträgt • IdM-Treiber • An das Verzeichnis angepasster Treiber, der die gesamte Logik der Verarbeitung beinhaltet

25. Zwei Modelle für die Anbindung

26. Modell 1: Institutsverzeichnis als führendes Quellverzeichnis Institut Verzeichnisdienstdes Instituts (z.B. Windows AD) • Modifikationen an Identitäten erfolgen nur und ausschliesslich im Quellverzeichnis des Instituts optional IdM-Portal • IdM-Portal: (https://idm.gwdg.de) • Benutzerverwaltung • Administration • SelfService MetaDirectory MPG-weite Authentifizierung Zentrale Diensteder GWDG Zentrale Diensteder MPG

27. Modell 2: IdM (eDirectory) als Quelle für Identitäten Institutsverzeichnis als Ziel Institut • Anlage/Löschen/Modifizieren von Identitätenerfolgen primär im IdM (über das Portal) und münden im Zielverzeichnis des Instituts • Sinnvoll, wenn auch mehrere Zielverzeichnisse existieren Verzeichnisdienstdes Instituts (z.B. Windows AD) Benutzerverwaltung IdM-Portal • IdM-Portal: (https://idm.gwdg.de) • Benutzerverwaltung • Administration • SelfService MetaDirectory MPG-weite Authentifizierung Zentrale Diensteder GWDG Zentrale Diensteder MPG

28. Beispiel-Ablauf: IdM-Treiber, Anlage eines Benutzers

29. Institut IdM der GWDG MetaDirectory verarbeitet DatenVorname: KarlNachname: TestuserUID: TestUserPasswort: *******eMail: testuser@mpi.de Benutzer wird lokal angelegtVorname: KarlNachname: TestuserUID: k.testuserPasswort: ******* eMail: testuser@mpi.de 3 1 IdM bildet lokale UIDaus Vor-, Nach-nameaus Vorname: Karlund Nachname: Testuserwird UID: karl.testuser RemoteLoader erkenntÄnderungenDaten/Attribute des Benutzer werden über RemoteLoader zum IdMübertragen 4 2 UPN wird im IdM gebildetaus UID + Realm wird der UPN gebildet UPN:karl.testuser@mpi.de 5 User wird im IdM angelegtUser: karl.testuserwird über das IdM in allen Zielsystemen der GWDG angelegt (Windows AD, LDAP etc.) 6 Administrator des Institutsbekommt eMail über Anlage des Benutzers 7

30. Angebundenes Verzeichnis des Instituts(hier am Beispiel Windows AD) IdM-Treiber Mapping: Attributszuordnung (Bsp: samAccountName = Unique ID) Regelwerk, Policies Filter für die Attribute(welche Attribut werden berücksichtigt) Zentrales Verzeichnis (eDirectory) eDirectory

31. Ausblick, Fazit, weitere Info‘s

32. Zukunft, Ausblick, Entwicklung … • Anbindung weiterer Max-Planck-Institute • Umsetzung der Nutzung des UPN in allen Diensten parallel zur UID • Die Anbindung an das IKT (GV, SAP/Netweaver) ist primäres Ziel • Auf- und Ausbau einer MPG-weiten, föderierten IAM Lösung • Einführung standardisierter Rollen

33. Fazit: • Ein zentrales, MPG-weites Verzeichnis ist die Voraussetzung für die effektive Nutzung gemeinsamer Dienste und Ressourcen • Die Anbindung von Instituten an das IdM ermöglicht den raschen Zugang zu zentralen Diensten • Die Anbindung ist für das Institut i.d.R mit wenig Aufwand verbunden • Die lokale Benutzerverwaltung kann dadurch entlastet werden • Die Institute behalten Ihre Autonomie bei der Benutzerverwaltung

34. weitere Info‘s zum Thema • GWDG-Nachrichten: • Ausgabe 9/2013 (Identity Management bei der GWDG) • Ausgabe 8/2013 (Identity Management als Dienstleistung) • Ausgabe 3/2013 (Das IdM-Portal) • Das GWDG IdM Team: • mail: idm@gwdg.de

35. Vielen Dank! … … Fragen ? Andreas Ißleiber (GWDG) andreas.issleiber@gwdg.de 0551/201-1815