Konzept Identity-Management

Unabhängig von der konkreten Produktauswahl ist das Konzept für eine technische Realisierung des IdM-Systems in Form eines Schichtenmodells fertiggestellt, vgl. dazu Abbildung. Der vorliegende Entwurf sieht eine möglichst weitgehende Modularisierung des Identity-Managements nach nachfolgend beschriebenen Modell vor und ist mit jedem der in der engeren Auswahl befindlichen Produkte realisierbar.

Die Architektur des Gesamtsystems besteht aus mehreren Schichten. Den Kern bildet der Identity-Manager, der die Daten speichert und wichtige Aufgaben wie eine Verwaltungsschnittstelle und Mechanismen zur Prozesssteuerung enthält.

Zur Gewinnung der Identitätsinformationen werden die verschiedenen Datenbanken der Fachanwendungen über eine Daten-Integrationsschicht an das IdMSystem angebunden. Diese Schicht hat die Aufgabe, unterschiedliche digitale Identitäten für eine reale Person zu identifizieren und zu einer digitalen Identität zusammen zu führen. Zusätzlich steuert sie den regelmäßigen Abgleich der Daten mit den Datenbanken der Fachanwendungen.

Die System-Integrationsschicht besteht aus wenigen eigenständigen Systemen, die mit den im IdM-System verwalteten digitalen Identitäten der Nutzer befüllt werden. Die Komponenten der System-Integrationsschicht liefern den angeschlossenen Diensten und Endsystemen der Hochschule die entsprechenden Schnittstellen zur Namensauflösung und Authentifizierung. Insbesondere wird durch diese Kapselung kein Endsystem direkt an den Identity-Manager angeschlossen.

Besonderheiten:

Das Projekt „Identity-Management“ unterscheidet sich von vergleichbaren Projekten anderer Hochschulen im Wesentlichen durch die folgenden beiden Punkte:

• Umfang der im IdM-System gespeicherten Daten
• Anzahl der vom IdM-System provisionierten IT-Systeme

Im geplanten IdM-System werden ausschließlich die Daten zu einer Person gespeichert, die entweder für die eindeutige Identifikation dieser Person notwendig sind oder die später für die Anbindung der verschiedenen IT-Systeme der System-Integrationsschicht benötigt werden. Anders als in den meisten Identity-Management-Konzepten anderer deutscher Hochschulen versteht sich das Identity-Management-System der Universität Augsburg damit nicht als umfassendes Auskunftssystem, sondern bildet vielmehr den Kern oder die Drehscheibe einer modular erweiterbaren, identitätsbasierten IT-Landschaft. Die im Teilprojekt AV entwickelte universitätsweite Adressverwaltung kann bereits als erste Anwendung (und modulare Funktionserweiterung) dieses Identity-Management-Kerns und damit als Proof-of-Concept betrachtet werden.

Was die Versorgung der personalisierten IT-Dienste anbetrifft, hat sich in der Betriebspraxis der vergangenen Jahre eine geschickte Kombination aus Provisionierung und System-Integration als vorteilhaft erwiesen. In der Konsequenz ist im IdM-Konzept der Universität Augsburg die oben beschriebene System-Integrationsschicht zur Konsolidierung der mit Identitätsinformationen zu versorgenden IT-Systeme vorgesehen. Die von den Anwendern tatsächlich genutzten IT-Dienste werden dann nicht direkt provisioniert, sondern in die Authentifizierungs- und Namensdienste der System-Integrationsschicht eingebunden. Die Anzahl der zu provisionierenden Systeme reduziert sich über diesen Ansatz auf (derzeit) zwei Systeme und die aufwändige Implementierung unzähliger Adapter zu den IT-Diensten entfällt. Aufgrund dieser Herangehensweise unterscheidet sich das Konzept ebenfalls von den meisten an anderen deutschen Hochschulen geplanten Identity-Management-Systemen, von denen mangels System-Integration meist eine Vielzahl unterschiedlichster IT-Dienste provisioniert werden muss.

Ein positiver und auch so gewollter Nebeneffekt der System-Integrationsschicht ist die strikte Entkopplung der von den Anwendern genutzten IT-Dienste vom Identity-Management. Aufgrund der gewählten Architektur können die Anwender sogar bei einem kompletten Ausfall des IdM-Systems unterbrechungsfrei mit den personalisierten IT-Diensten der Universität Augsburg (z. B. E-Mail, VPN, Web-Anwendungen) weiterarbeiten. Außerdem erlaubt die Entkopplung, dass einzelne Komponenten ausgetauscht werden können (wie es bei dem im Projektverlauf eingeplanten Übergang von DCE zu MIT Kerberos V/OpenLDAP bereits notwendig sein wird).