Upload
natara
View
65
Download
0
Embed Size (px)
DESCRIPTION
Identity Management für die Max-Planck-Institute. 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 - PowerPoint PPT Presentation
Citation preview
Identity Management für die Max-Planck-Institute
Andreas Ißleiber (GWDG) [email protected] 0551/201-1815
2
• 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
Inhalt
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/VerzeichnisdiensteInstitution Anzahl
IdentitätenAnzahl angebundener Verzeichnisse
GWDG 2105 11
Max-Planck 12598 19
Studierende 32635 3
Universität 34992 6
Universitätsmedizin 8100 2
Summe: 90430 41
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
Diverse Prozesse und Scripts
Windows Exchange der GWDG
MetaDirectory(Identity Vault)
Windows AD der GWDG
Diverse Max-Planck-InstituteWindows AD, LDAP, db
DatenquelleDatensenke
Legende
Angebundene Verzeichnisse am IdM
LDAP der GWDG
Benutzer-Portal
Diverse Universitäts-Institute
Sudierende (HIS)
Sudierende (FlexNow)
IdM-Portal
Klinikum (UMG)der Universität
SAP der Universität
In 2011: Einführung der Mandantentrennung (Max-Planck/Universität) im IdMTrennung der Bereiche in unterschiedliche Partitionen
Bausteine des IdM der GWDG(Technische Zusammenhänge)
Bausteine des IdMbei der GWDG
Entwicklungsumgebung
MetaDirectory Periphäre SystemeZentrale Authentifizierung
Zentrale Authentifizierung
11
eDirectory Replica-Ring
idm1MetaDir
idm2MetaDir
Master-Replica MetaDirectory Main Server IdM-Driver Management
Read/Write-Replica IdM-Driver (failover)
MetaDirectory
ProductiveeDirectory
1
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
Auf idm1 läuft die „Logik“ sämtlicher Prozesse in Form von Treibern
Das MetaDirectory
12
IdM PortalWeb-Portal
Reporting&
Monitoring
Periphäre Systeme
SyslogServer
http://idm.gwdg.de SelfService Managing
Monitoring Reporting Logging
Logging Tracing
SubversionServer
SVN
2
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-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
Periphäre IdM-Systeme
13
Idm1 (devel)MetaDir
Idm2 (devel)MetaDir
Master-Replica Driver Developing Testing
Read/Write-Replica
Entwicklungsumgebung
DevelopmenteDirectory
SAPDeveloping
Master-Replica SAP IdM
Developing
3
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
Entwicklungsumgebung
IdM-Entwicklungsumgebung getrennt/isoliert vom Produktivsystem
14
Idm1.backupMetaDir
Idm2.backupMetaDir
Master-Replica IdM-Driver (offline) IdM Management
Read/Write-Replica (offline)
Disaster-Recovery
BackupeDirectory
4
TSM Backup
GWDG Backupsystem
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)
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
Win
dow
s AD
LDAP
RADI
US
GWDG Authentication Servers
Authentifizierung
Services
5 Authentifizierungsserver
Zentrale Authentifizierungssysteme- Windows AD der GWDG- LDAP der GWDG- RADIUS Server der GWDG
Zugang zu zentralen Diensten der GWDG über …- Windows AD der GWDG- LDAP der GWDG- RADIUS Server der GWDG
Zentrale Diensteder GWDG
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
Anbindung von Max-Planck Institutenam IdM der GWDG
21
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
22
Anbindung eines Instituts an das IdM4) 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)
23
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
24
Remote loader
MetaDirectory
Verschlüsselte Verbindung
Verzeichnisdienstdes Instituts
IdM-Treiber
Internet
Firewall(TCP:8090)
GWDGFirewall
MPI-Institut
IdM Server
Technische Anbindung eines Instituts
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
Zwei Modelle für die Anbindung
26
Verzeichnisdienstdes Instituts(z.B. Windows AD)
IdM-Portal: (https://idm.gwdg.de) Benutzerverwaltung Administration SelfService
Zentrale Diensteder GWDG
IdM-Portal
Institut
MetaDirectory
Zentrale Diensteder MPG
MPG-weite Authentifizierung
Modell 1: Institutsverzeichnis als führendes Quellverzeichnis
- Modifikationen an Identitäten erfolgen nur und ausschliesslich im Quellverzeichnis des Instituts
optional
27
Verzeichnisdienstdes Instituts(z.B. Windows AD)
IdM-Portal: (https://idm.gwdg.de) Benutzerverwaltung Administration SelfService
Zentrale Diensteder GWDG
IdM-Portal
Institut
MetaDirectory
Zentrale Diensteder MPG
MPG-weite Authentifizierung
Benutzerverwaltung
Modell 2: IdM (eDirectory) als Quelle für Identitäten Institutsverzeichnis als Ziel
- 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
Beispiel-Ablauf: IdM-Treiber, Anlage eines Benutzers
29
Benutzer wird lokal angelegtVorname: KarlNachname: TestuserUID: k.testuserPasswort: *******eMail: [email protected]
RemoteLoader erkenntÄnderungenDaten/Attribute des Benutzer werden über RemoteLoader zum IdM übertragen
MetaDirectory verarbeitet DatenVorname: KarlNachname: TestuserUID: TestUserPasswort: *******eMail: [email protected]
IdM bildet lokale UIDaus Vor-, Nach-nameaus Vorname: Karlund Nachname: Testuserwird UID: karl.testuser
User wird im IdM angelegtUser: karl.testuserwird über das IdM in allen Zielsystemen der GWDG angelegt(Windows AD, LDAP etc.)
UPN wird im IdM gebildetaus UID + Realm wird der UPN gebildet UPN:[email protected]
Administrator des Institutsbekommt eMail über Anlage des Benutzers
Institut IdM der GWDG
1
2
3
4
5
6
7
30Zentrales Verzeichnis (eDirectory)
Regelwerk, Policies
Filter für die Attribute(welche Attribut werden berücksichtigt)
Mapping: Attributszuordnung(Bsp: samAccountName = Unique ID)
Angebundenes Verzeichnis des Instituts(hier am Beispiel Windows AD)
eDirectory
IdM-Treiber
Ausblick, Fazit, weitere Info‘s
32
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
Zukunft, Ausblick, Entwicklung …
33
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
Fazit:
34
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]
weitere Info‘s zum Thema