Transcript IdM DV-Treffen 2013

Identity Management für die Max-PlanckInstitute
Andreas Ißleiber (GWDG)
[email protected]
0551/201-1815
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
2
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
Eckdaten des IdM bei der GWDG
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
Institution
Anzahl
Identitäten
Anzahl angebundener
Verzeichnisse
2105
11
Max-Planck
12598
19
Studierende
32635
3
Universität
34992
6
8100
2
90430
41
GWDG
Universitätsmedizin
Summe:
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
Angebundene Verzeichnisse am IdM
Angebundene Verzeichnisse am IdM
Legende
Datenquelle
Datensenke
Klinikum (UMG)
der Universität
Diverse Max-Planck-Institute
Windows AD, LDAP, db
Diverse Universitäts-Institute
Windows AD der GWDG
Windows Exchange der GWDG
LDAP der GWDG
MetaDirectory
(Identity Vault)
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
Bausteine des IdM der GWDG
(Technische Zusammenhänge)
Bausteine des IdM
bei der GWDG
Entwicklungsumgebung
Zentrale
Authentifizierung
MetaDirectory
Zentrale
Authentifizierung
Periphäre Systeme
MetaDirectory
idm1
MetaDir
eDirectory
Replica-Ring





Master-Replica
MetaDirectory
Main Server
IdM-Driver
Management


1
idm2
MetaDir
Read/Write-Replica
IdM-Driver (failover)
Productive
eDirectory
Das MetaDirectory
 MetaDirectory als Basis
(zentraler Verzeichnisdienst)
 Vollständig redundante Auslegung des
Verzeichnisdienstes (eDirectory)
(durch zwei Server: idm1 & idm2)
 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
11
 Auf idm1 läuft die „Logik“ sämtlicher Prozesse in Form von Treibern
Periphäre Systeme
Reporting
&
Monitoring
2
IdM Portal
Web-Portal
Periphäre IdM-Systeme
 Idm-portal
 http://idm.gwdg.de
 Selfservice (Passwortänderungen etc.)
Subversion
Syslog
 Administration für die Kunden
Server
Server
 Anlage, Modifikation der Benutzer
 Eigene Arbeitsumgebung für jeden Kunden
 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
12
 Möglichkeit zu älteren Treiberversionen zurück zu kehren



Monitoring
Reporting
Logging





Logging
Tracing
http://idm.gwdg.de
SelfService
Managing

SVN
Entwicklungsumgebung
Master-Replica
Driver Developing
Testing
Development
eDirectory
Entwicklungsumgebung
Idm2 (devel)
MetaDir
Idm1 (devel)
MetaDir



3

Read/Write-Replica
SAP
Developing


 IdM-Entwicklungsumgebung
getrennt/isoliert vom Produktivsystem
Master-Replica
SAP IdM
Developing
 Eigenschaften der Entwicklungsumgebung:
 Realistische Arbeitsumgebung (>= 90.000 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
13
Disaster-Recovery
Idm2.backup
MetaDir
Idm1.backup
MetaDir




Master-Replica
IdM-Driver (offline)
IdM Management
Backup
eDirectory
4

Read/Write-Replica
(offline)
TSM Backup
Disaster Recovery/Backup
 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)
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
14
Authentifizierung
5
Authentifizierungsserver
LDAP
Windows AD
RADIUS
GWDG Authentication Servers
 Zentrale Authentifizierungssysteme
 Windows AD der GWDG
 LDAP der GWDG
 RADIUS Server der GWDG
 Zugang zu zentralen Diensten der GWDG über …
Zentrale Dienste
 Windows AD der GWDG
der GWDG
 LDAP der GWDG
 RADIUS Server der GWDG
15
Umsetzung eines MPG-weiten
föderativen Verzeichnisses
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
17
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.)
18
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
19
Anbindung von Max-Planck Instituten
am IdM der GWDG
Anbindung eines Instituts an das IdM
1) 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
2) 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
3) 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
21
Anbindung eines Instituts an das IdM
4) 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 (eMail)
5) Programmierung/Anpassung des Treibers und Dokumentation (GWDG)
 Basierend auf dem Fragenkatalog wird der Treiber installiert/angepasst
 Gleichzeitig wird mir der Dokumentation der Anbindung begonnen
6) 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)
22
Anbindung eines Instituts an das IdM
7) Einrichten der Arbeitsumgebung am IdM-Portal
 Für die Administratoren des Instituts wird die Arbeitsumgebung den
Wünschen des Instituts entsprechend eingerichtet
8) 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
23
Technische Anbindung eines Instituts
MPI-Institut
Verzeichnisdienst
des Instituts
MetaDirectory
GWDG
Firewall
Firewall
(TCP:8090)
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
24
Zwei Modelle für die Anbindung
Modell 1: Institutsverzeichnis als führendes
Quellverzeichnis
Institut
Verzeichnisdienst
des Instituts
(z.B. Windows AD)
 Modifikationen an Identitäten erfolgen nur und
ausschliesslich im Quellverzeichnis des Instituts
optional
IdM-Portal
MetaDirectory
IdM-Portal:
(https://idm.gwdg.de)
 Benutzerverwaltung
 Administration
 SelfService
MPG-weite
Authentifizierung
Zentrale Dienste
der GWDG
Zentrale Dienste
der MPG
26
Modell 2: IdM (eDirectory) als Quelle für Identitäten
Institutsverzeichnis als Ziel
Institut
Verzeichnisdienst
des Instituts
(z.B. Windows AD)
 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
Benutzerverwaltung
IdM-Portal
MetaDirectory
IdM-Portal:
(https://idm.gwdg.de)
 Benutzerverwaltung
 Administration
 SelfService
MPG-weite
Authentifizierung
Zentrale Dienste
der GWDG
Zentrale Dienste
der MPG
27
Beispiel-Ablauf: IdM-Treiber,
Anlage eines Benutzers
Institut
Benutzer wird lokal
angelegt
Vorname: Karl
Nachname: Testuser
UID: k.testuser
Passwort: *******
eMail: [email protected]
RemoteLoader erkennt
Änderungen
Daten/Attribute des
Benutzer werden über
RemoteLoader zum IdM
übertragen
IdM der GWDG
1
2
MetaDirectory verarbeitet Daten
Vorname: Karl
Nachname: Testuser
UID: TestUser
Passwort: *******
eMail: [email protected]
3
IdM bildet lokale UID
aus Vor-, Nach-name
aus Vorname: Karl
und Nachname: Testuser
wird UID: karl.testuser
4
UPN wird im IdM gebildet
aus UID + Realm wird der
UPN gebildet
UPN:[email protected]
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 eMail über
Anlage des Benutzers
7
29
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)
30
Ausblick, Fazit, weitere Info‘s
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
32
 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
33
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: [email protected]
34
Vielen Dank! …
… Fragen ?
Andreas Ißleiber (GWDG)
[email protected]
0551/201-1815
35