Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Identity Management für die Max-Planck-Institute

Ähnliche Präsentationen


Präsentation zum Thema: "Identity Management für die Max-Planck-Institute"—  Präsentation transkript:

1 Identity Management für die Max-Planck-Institute
Andreas Ißleiber (GWDG) /

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 Identitäten und 41 angebundener Verzeichnisse/Verzeichnisdienste Institution Anzahl Identitäten Anzahl angebundener Verzeichnisse GWDG 2105 11 Max-Planck 12598 19 Studierende 32635 3 Universität 34992 6 Universitätsmedizin 8100 2 Summe: 90430 41

6 Eckdaten des IdM bei der GWDG
Produkt: Novell/NetIQ Identity Manager 4.02 (incl. eDirectory) Kommunikation, sowie Programmierung  XML (DirXML) Ereignisse/Modifikationen ca – / Tag Angebundene Systeme: Windows AD ( ) 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-Institute Windows AD, LDAP, db Klinikum (UMG) der Universität Diverse Universitäts-Institute Windows AD der 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 IdM Trennung der Bereiche in unterschiedliche Partitionen

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

10 Bausteine des IdM bei der GWDG
Entwicklungsumgebung Zentrale Authentifizierung MetaDirectory Periphäre Systeme Zentrale Authentifizierung

11 eDirectory Replica-Ring ProductiveeDirectory
Das MetaDirectory MetaDirectory 1 idm1 MetaDir idm2 MetaDir MetaDirectory als Basis (zentraler Verzeichnisdienst) Vollständig redundante Auslegung des Verzeichnisdienstes (eDirectory) (durch zwei Server: idm1 & idm2) eDirectory Replica-Ring Master-Replica MetaDirectory Main Server IdM-Driver Management Read/Write-Replica IdM-Driver (failover) ProductiveeDirectory Idm1 & idm2 laufen in der Servervirtualisierung (vmWare)  Vorteile: Failover, verteilte Standorte, Lastverteilung, Snapshots Permanente Replikation zwischen Master Replica (idm1) read/write Replica (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 Reporting & Monitoring
Periphäre Systeme Periphäre IdM-Systeme 2 Reporting & Monitoring IdM Portal Web-Portal Idm-portal Selfservice (Passwortänderungen etc.) Administration für die Kunden Anlage, Modifikation der Benutzer Eigene Arbeitsumgebung für jeden Kunden Monitoring Reporting Logging SelfService Managing Syslog Server Subversion 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 Development eDirectory
3 Entwicklungsumgebung Idm1 (devel) MetaDir Idm2 (devel) MetaDir IdM-Entwicklungsumgebung getrennt/isoliert vom Produktivsystem Master-Replica Driver Developing Testing Read/Write-Replica SAP Developing Development eDirectory Master-Replica SAP IdM Developing Eigenschaften der Entwicklungsumgebung: Realistische Arbeitsumgebung (>= User) Treiberentwicklung Testläufe/Last-Tests z.B. vor Produktivsetzung im Realsystem Bulk change Manipulationen am eDirectory Test von Software Update/Upgrades SAP-Treiber Entwicklung Getrennter Bereich für die Entwicklung der Anbindung von SAP am IdM

14 Disaster Recovery/Backup
4 Idm1.backup MetaDir Idm2.backup MetaDir 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) Master-Replica IdM-Driver (offline) IdM Management Read/Write-Replica (offline) TSM Backup Backup eDirectory 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 GWDG Authentication Servers
Authentifizierung Authentifizierungsserver 5 GWDG Authentication Servers Zentrale Authentifizierungssysteme Windows AD der GWDG LDAP der GWDG RADIUS Server der GWDG RADIUS Windows AD LDAP Services Zugang zu zentralen Diensten der GWDG über … Windows AD der GWDG LDAP der GWDG RADIUS Server der GWDG Zentrale Dienste der 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: IdM as a Service
Bestandteile von IdM as 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, Cloud share Dienste) Optional (IdM as 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 Verzeichnis erkennt 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 Zustand automatisch informiert werden ( ) 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 Produktivumgebung für die Anbindung

24 Verschlüsselte Verbindung
Technische Anbindung eines Instituts MPI-Institut Verzeichnisdienst des Instituts MetaDirectory Firewall (TCP:8090) GWDG Firewall IdM Server Internet Remote loader Verschlüsselte Verbindung IdM-Treiber RemoteLoader Client-Software (Java), welche die Ereignisse im Verzeichnis erkennt 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
Verzeichnisdienst des 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 Dienste der GWDG Zentrale Dienste der MPG

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

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

29 Institut IdM der GWDG MetaDirectory verarbeitet Daten Vorname: Karl Nachname: Testuser UID: TestUser Passwort: ******* Benutzer wird lokal angelegt Vorname: Karl Nachname: Testuser UID: k.testuser Passwort: ******* 3 1 IdM bildet lokale UID aus Vor-, Nach-name aus Vorname: Karl und Nachname: Testuser wird UID: karl.testuser RemoteLoader erkennt Änderungen Daten/Attribute des Benutzer werden über RemoteLoader zum IdM übertragen 4 2 UPN wird im IdM gebildet aus UID + Realm wird der UPN gebildet 5 User wird im IdM angelegt User: karl.testuser wird über das IdM in allen Zielsystemen der GWDG angelegt (Windows AD, LDAP etc.) 6 Administrator des Instituts bekommt ü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) eDirectory Zentrales Verzeichnis (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:

35 Vielen Dank! … … Fragen ? Andreas Ißleiber (GWDG) /


Herunterladen ppt "Identity Management für die Max-Planck-Institute"

Ähnliche Präsentationen


Google-Anzeigen