Cloud-First Identity Management - Wie wir den MIM in den Ruhestand schicken

post-thumb

Quo Vadis, Microsoft Identity Manager?

Viele große Unternehmen setzen den Microsoft Identity Manager (MIM) als zentrales Tool für die Verwaltung ihrer digitalen Identitäten ein. Der MIM bietet ein über Jahre im langjährigen Unternehmenseinsatz bewährtes Software-Paket, das das Management von Identitäten aus einem Quell-System – in der Regel handelt es sich um ein HR-Tool wie etwa Workday oder SuccessFactors - in eines oder mehrere Zielsysteme übernimmt. Hier zählt das Active Directory zu den Standard-Datensenken. Der MIM verfügt dabei über zahlreiche Funktionalitäten, um Nutzer und Gruppen in einem integrierten System entlang des typischen Starter-Mover-Leaver Identitäts-Lebenszyklus abzubilden.[1] So weit, so sinnvoll.

Und wo ist das Problem?

Im Kern liegt die Schwierigkeit des MIM darin, dass er sowohl konzeptionell als auch technisch als reines OnPremises-Tool aufgesetzt wurde und von Microsoft seit Anfang 2021 nicht mehr weiterentwickelt wird. Auch wenn das offizielle Supportende vor kurzem ins Jahr 2029 nach hinten verschoben wurde, ist klar, dass in einer zukunftsgerichteten Identity-Architektur der MIM keine Rolle mehr spielen wird.

Dies zeigt sich in der Praxis in nicht mehr zeitgemäßen täglichen Synchronisierungs-Intervallen. Dies kann beispielsweise dazu führen, dass ein Mitarbeiter, der das Unternehmen verlassen muss, im HR-System am Montagmorgen gesperrt wird und den Zugriff auf sämtliche Unternehmens-Ressourcen unverzüglich verlieren sollte. Durch den täglichen Synchronisierungs-Intervall erfolgt dies jedoch in der Nacht von Montag auf Dienstag, sodass der Nutzer erst am Folgetag die Zugriffsrechte entzogen bekommt und noch beinahe 24 Stunden lang Zeit hat auf Unternehmensdaten zuzugreifen.

Die Komplexität der IDM-Prozesse, die durch den MIM verwaltet werden, erschwert eine einfache Migration in Richtung einer einzelnen cloudbasierten Anwendung, die darüber hinaus am Markt einfach nicht existiert – weder von Microsoft noch von einem spezialisierten Software-Provider. So entsteht überspitzt formuliert der unten abgebildete Kampf David (repräsentiert durch cloudbasierte Identity-Tools wie das Azure AD) gegen Goliath (mit dem MIM im Verbund mit dem lokalen Active Directory).

Identity Management OnPremises vs. Cloud - ein Kampf David gegen Goliath? Identity Management OnPremises vs. Cloud - ein Kampf David gegen Goliath?

Welche Strategie verfolgen wir bei Objektkultur?

Um trotz des Status Quo eine zukunftsgerichtete Perspektive zur automatisierten Verwaltung digitaler Identitäten aufzeigen zu können, verfolgt Objektkultur konsequent eine Cloud-First IDM-Strategie gemeinsam mit seinen IDM-Kunden. Doch was bedeutet das in der Praxis?

Dies bedeutet zunächst einmal die konsequente Ausrichtung sämtlicher Neu-Entwicklungen und Prozess-Optimierungen am Cloud First-Paradigma. Wir bauen daher keine neue Komplexität in den MIM in Form von Extensions ein, sondern verlagern IDM-Workloads in Richtung Cloud-Technologien und - Schnittstellen. Zuvorderst haben sich in diesem Zusammenhang Azure Functions bewährt. Diese erlauben es dem IDM-Entwickler, sich - gemäß des Serverless Computing-Paradigmas - auf die Business-Logik der Anforderung zu konzentrieren, während die Cloud-Infrastruktur durch Microsoft gemanagt wird.

Um diese Strategie mit Leben zu füllen, möchte ich aus meinem Projektalltag einen konkreten Workload vorstellen, der bei einem unserer IDM-Kunden - einem international tätigen Chemie-Unternehmen – produktiv im Einsatz ist.

Automatisiertes Service Desk User Onboarding

In unserem Kundenszenario werden neue Mitarbeiter 14 Tage vor ihrem Vertragsbeginn im HR-System angelegt und über den MIM in Richtung AD und Azure AD provisioniert. Damit der Vorgesetzte sich rechtzeitig um die Arbeitsausstattung (Hardware / Lizenzen) des neuen Kollegen kümmern kann, haben wir gemeinsam mit unserem Kunden einen automatisierten Onboarding-Prozess etabliert, bei dem für jedes neue Nutzerobjekt im Azure AD automatisiert ein Ticket in Freshservice, dem cloudbasierten Service-Desk Tool des Kunden, angelegt wird. Der technische Prozess umfasst ausschließlich cloudbasierte Tools und Schnittstellen und ist im folgenden Schaubild dargestellt:

Erstellen eines Onboarding Requests im Service Desk-Tool? Erstellen eines Onboarding Requests im Service Desk-Tool

Die FunctionApp wird intervallbasiert alle vier Stunden ausgeführt und prüft zunächst per Graph-Abfrage, ob neue interne Mitarbeiter im Azure AD vorhanden sind. Für alle neuen Mitarbeiter durchläuft die App dann die folgenden Schritte:

  1. Hole alle für den Onboarding-Request nötigen Attribute aus dem Azure AD Nutzerobjekt per Graph API
  2. Um die ID der Nutzer-Location zu bekommen, erfolgt eine GET-Abfrage gegen die API des Service Desk-Tools
  3. Validiere, ob alle Pflichtattribute für das Nutzerobjekt gefüllt sind.
  4. Der finale Onboarding Request wird per POST-Methode an die Service Desk-API gesendet.
  5. Im Azure AD wird für den Benutzer ein Flag in einem Extension Attribute gesetzt, damit für diesen Nutzer kein weiterer Onboarding-Request mehr erfolgen wird.

Die wichtigsten Take-Aways

Neben diesem Service Desk-Workload haben wir bei dem beschriebenen Kunden im Jahr 2022 mehrere Cloud-Workloads umgesetzt und hier primär Azure FunctionApps sowie PowerApps in Kombination mit SharePoint Online und anderer O365-Features eingesetzt.

So konnten wir es schaffen, die Komplexität des MIM trotz diverser Prozess-Automatisierungen insgesamt zu reduzieren, während sich die Zugriffe per Graph API auf das Azure AD vervielfachten.

Eine der wichtigen Erkenntnisse war an dieser Stelle, dass es schon ab dem zweiten Workload wichtig ist sich zu übergreifenden Function App-Strukturen Gedanken zu machen. So wird sichergestellt, dass die implementierten Lösungen skalierbar und wartbar bleiben. Dies kann zum Beispiel dadurch gewährleistet werden, dass man globale Konfigurationswerte in eine übergeordnete Instanz auslagert und nur die Workload-spezifischen Konfigurationen in der Function App verbleiben. Auch eine intelligente Strukturierung der zum Speichern von ClientSecrets und Zertifikaten genutzten Azure KeyVaults kann einem doppelte Konfigurations-Arbeit ersparen.

Des Weiteren haben wir in den Tiefen der Benutzerverwaltung an verschiedenen Stellen gelernt, dass der Microsoft Graph hier bei weitem noch nicht auf dem Funktionsstand ist, wie es der bisherige Standard Azure AD Graph nach wie vor ist.[2] So sind manche standardmäßigen Filter-Bedingungen bisher nur mit Workarounds oder mithilfe der nicht für eine produktive Nutzung empfohlenen Beta-Version der Graph API realisierbar.

Die Zukunft des Cloud-First Identity Management

Richten wir den Blick weiter in die Zukunft, erwarten uns in den kommenden Monaten und Jahren viele spannende Features auf Basis der in diesem Jahr neu eingeführten Microsoft Entra-Plattform. So werden die aktuell in Public Preview-Status befindlichen Lifecycle Workflows den oben beschriebenen Kundencase weiter vereinfachen, indem man konfigurativ und mithilfe von vorgefertigten Szenarien den Starter-Prozess basierend auf der Provisionierung des Nutzers im Azure AD automatisieren kann. Erweiterte Business-Logik, wie das Erstellen eines Service Requests im ITSM-Tool, lässt sich durch das zusätzliche Einbinden einer Logic App leichtgewichtig implementieren.

So wird in der IDM-Praxis künftig eine eine mehrgleisige Strategie an Bedeutung gewinnnen, indem man einerseits die neuen Funktionalitäten auf Basis der Microsoft Entra-Plattform einsetzt. Zum anderen werden aber auch vollständig Eigenentwicklungen mittels Azure Function Apps-basierte Workloads weiter eine große Rolle spielen, um langfristig alle Business-Logik aus dem MIM herauszulösen und diesen beim Kunden final abschalten zu können.


[1] Dem an einem noch tieferen Einstieg in IDM-Themen interessierten Leser sei an dieser Stelle der überaus lesenswerte Blog-Beitrag meines Kollegen Timo Schweikart zum Thema Identity Lifecycles empfohlen.

[2] Weshalb es dennoch sinnvoll ist, auf MS Graph zu setzen, verdeutlicht Microsoft im hier verlinkten Migrations-Tutorial.

Der Objektkultur-Newsletter

Mit unserem Newsletter informieren wir Sie stets über die neuesten Blogbeiträge,
Webcasts und weiteren spannende Themen rund um die Digitalisierung.

Newsletter abonnieren