Effiziente Identitätserstellung mit API-driven Provisioning – die neue Schnittstelle in Microsoft Entra ID

Identitäten von Mitarbeitenden anlegen, verarbeiten und löschen – mit diesem Thema sieht sich nahezu jedes Unternehmen konfrontiert. In der Regel kommt dafür ein Identity & Access Management (IAM) zum Einsatz. Dieses System stellt - vergleichbar mit einem Portier am Eingang eines Luxushotels - sicher, dass nur berechtigte Personen das Gebäude betreten. Auf diese Weise wird es einer Organisation ermöglicht, den sicheren Zugriff auf ihre digitalen Ressourcen zu verwalten und Berechtigungen von Identitäten an zentraler Stelle zu prüfen.

Indem nur denjenigen Personen Zugang zu Applikationen, Daten und Prozessen gewährt wird, die diesen Zugang für ihre Arbeit wirklich benötigen, wird auch die Sicherheit und der Datenschutz von Unternehmensressourcen verbessert.

Der Support für den Microsoft Identity Manager endet

Für bisherige On-premises-Lösungen im IAM-Bereich wurde oft der Microsoft Identity Manager (MIM) eingesetzt. Mit dem für 2029 angekündigten Supportende für den MIM erhöht sich der Handlungsdruck für IT-Entscheider*innen, eine nachfolgende Lösung zu finden, über die das Identity & Access Management zukünftig realisiert werden kann.

Migrationen in diesem Bereich sind aufgrund ihrer Verzahnung mit anderen IT-Systemen und -Prozessen in der Regel komplex. Fehler können mit Datenlecks, Betriebsunterbrechungen und Compliance-Verstößen weitreichende Folgen haben. Gleichzeitig ist der Einsatz einer zentralen Identitätsmanagement-Software für Unternehmen als Beitrag zur IT-Sicherheit oft unverzichtbar - getreu dem Motto “Hackers don’t break in, they log in”. Zudem ist das Identity & Access Management ein fester Bestandteil von Standards wie der ISO 27001 oder der EU-Datenschutzgrundverordnung.

Checkliste zur IAM-Einführung: Diese Fragen sollten Sie sich bei der IAM-Implementierung stellen.

Die Produktfamilie von Microsoft Entra ID

Um die Anforderungen an Standards und Governance-Richtlininen auch zukünftig erfüllen zu können, bietet Microsoft mit Entra ID als Teil der hier gezeigten Entra-Produktfamilie eine moderne, cloud-basierte Lösung.

Die ehemals als Azure AD bezeichneten Angebote bündeln Dienste rund um das Identity & Access Management und integrieren in diesem Zusammenhang immer mehr Funktionen des MIM. Um Unternehmen, die beispielsweise auf Grund von On-premises-Anwendungen weiterhin ein lokales Active Directory verwenden müssen, den Übergang zu Entra zu erleichtern, bietet Microsoft eine Lösung mit Hybrididentitäten an. Dadurch können sowohl lokale als auch in der Cloud angesiedelte Anwendungen angebunden werden.

Darum geht’s: die generische Schnittstelle von Entra

Viele Leserinnen und Leser dürften sich fragen, welche Neuigkeiten dieser Beitrag erzählt. So wurde das Ende des MIM bereits vor einigen Jahren angekündigt und auch die Umbenennung von Azure AD in Entra ist schon fast ein alter Hut. Daher soll dieser Beitrag weder die Funktionalitäten des MIM noch von Entra aufzeigen. Stattdessen werden die Ergebnisse einer intern durchgeführten Analyse vorgestellt, welche die Möglichkeit testet, Anwendungen über eine generische Schnittstelle mit Entra zu verbinden. Dadurch soll die Hürde einer Migration, für jede Anwendung einen eigenen Connector zu implementieren, gesenkt werden. Zu diesem Zweck wurde eine prototypische Umgebung entwickelt, die die wesentlichen Funktionen eines IAM realisiert und welche zukünftig als Anschauungs- und Demonstrationsmodell dienen kann.

Während bisherige Lösungen für jede Anwendung einen individuellen Connector erforderten, verspricht die neue, als „API-driven inbound Provisioning“ bezeichnete Schnittstelle, dass beliebige Daten im SCIM-Standard an Entra gesendet werden können. Die Verarbeitung der Daten soll anschließend innerhalb von Entra weitgehend automatisiert ablaufen. Um diese Schnittstelle zu testen, wurde im Prototyp der Analyse die hier gezeigte Umgebung aufgebaut. Dabei wurde der nach unserer Erfahrung in vielen Unternehmen vorherrschende Fall einer hybriden Umgebung realisiert. Eine reine Cloud-Anwendung ist jedoch ebenso möglich.

Um ein allgemeines Szenario abzubilden und eine Vorlage für individuelle Kundenszenarien zu erstellen, realisiert der für die Analyse konzipierte Prototyp die Bereitstellung von Mitarbeiterdaten aus einem HR-System. Diese Bereitstellung ist eine Voraussetzung, damit ein Unternehmen die Daten von Mitarbeitenden über ein IAM-System verarbeiten kann.

Um den Prototyp dabei allgemeingültig zu halten, wird auf die Implementierung eines spezifisches HR-Systems verzichtet. Stattdessen werden in Schritt 1 der Abbildung die Daten als reiner HTTPS-Request durch Postman direkt an den neuen Endpunkt gesendet. Von hier erfolgt in Schritt 2 über den Entra ID Provisioning Service die weitere Verarbeitung. Dabei werden die Daten in Schritt 3 zunächst im lokalen AD angelegt. In den Schritten 4 und 5 erfolgt anschließend die Synchronisierung zu Entra. Andere Systeme können die Daten in den Schritten 6 und 7 von Entra abrufen und intern weiterverarbeiten. Daten, wie beispielsweise eine in Entra erstellte E-Mail-Adresse, können so in die Nutzeridentität im HR-System synchronisiert werden.

Konfiguration der Schnittstelle in Entra

Bevor die Schnittstelle angesprochen werden kann, muss die Schnittstelle konfiguriert werden. Die Konfiguration gleicht dabei dem Einrichten eines Connectors für eine spezifische Anwendung. Im Entra-Produktkatalog kann die als „API-driven inbound Provisioning“ bezeichnete Unternehmensanwendung, wie beispielhaft dargestellt, konfiguriert werden.

Nach der Konfiguration erhält man einen Endpunkt, welcher beispielsweise über Postman angesprochen werden kann. Um über die Schnittstelle jedoch Nutzer anlegen oder ändern zu können, müssen die entsprechenden Berechtigungen hinterlegt werden. Dafür setzt Microsoft wie bereits für bestehende Anbindungen zu Services auf vorgefertigte Connectoren und stellt einen als „API-driven Provisioning“ bezeichneten Connector bereit. Dieser ermöglicht die Verbindung zwischen beliebigen Anwendungen und Entra ID.

Ist die Konfiguration so weit abgeschlossen, müssen die Authentifizierungsinformationen in Postman hinterlegt werden. Im hier gezeigten Beispiel wird dabei das OAuth-Protokoll verwendet.

Anschließend kann mit der Bereitstellung der User begonnen werden. Ein möglicher Request kann in der folgenden Form vorliegen:

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:BulkRequest"],
    "Operations": [{
            "method": "POST",
            "bulkId": "897401c2-2de4-4b87-a97f-c02de3bcfd70",
            "path": "/Users",
            "data": {
                "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User",
                    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
                    "urn:ietf:params:scim:schemas:extension:csv:1.0:User"],
                "id": "2819c223-7f76-453a-919d-413861904700",
                "externalId": "521200",
                "userName": "bmaier",
                "accountDisabled": true,
                "name": {
                    "familyName": "Maier",
                    "givenName": "Bob"
                },
                "displayName": "Bob Maier",
                "nickName": "Bob"
                },
                "urn:ietf:params:scim:schemas:extension:csv:1.0:User": {
                    "HireDate": "2023-12-01T00:00:00-05:00"
                }
            }
    ],
    "failOnErrors": null
} 

Der dargestellte Request kann durch viele weitere, optionale Attribute ergänzt werden und so die digitale Identität des Mitarbeitenden mit Informationen ausstatten. Für die Schnittstelle ist zu beachten, dass in der aktuellen Version lediglich POST-Requests verarbeitet werden können. Soll ein User gelöscht werden, wird der Request in Entra ID entsprechend interpretiert. Das Attribut method: POST muss dazu zu einem method: DELETE geändert werden. Der Request selbst verbleibt jedoch ein POST-Request.

Um zu prüfen, ob der Request erfolgreich durchgeführt werden konnte, können die Logfiles in Entra betrachtet werden. Mögliche Fehler könnten in einer doppelten Belegung von IDs zu finden sein.

Fazit

Für Unternehmen, welche ihr bisheriges IAM-System ablösen und den Weg in die Cloud beschreiten möchten, bietet die neue Schnittstelle die Möglichkeit, den Migrationsaufwand erheblich zu reduzieren. Dabei gilt, dass neben HR-Systemen auch andere Systeme über die Schnittstelle angebunden werden können, welche zuvor oft individuelle Connectoren benötigten.

Auch wenn die Migration nur in Teilen vollzogen werden soll, bietet die Schnittstelle eine Chance, den Aufwand zu reduzieren. Aktuelle Einschränkungen, wie z.B. die ausschließliche Bearbeitung von POST-Requests, gilt es gegen Vorteile wie die einfache Inbetriebnahme der Schnittstelle und die vielseitigen Einsatzmöglichkeiten abzuwägen.

Für Kunden, die neben dem Migrationsaufwand auch die Betreuung des Identity & Access Managements an einen spezialisierten Dienstleister auslagern möchten, bietet Objektkultur die Dienstleistung Identity & Access Management as a Service (IAMaaS) an.

Checkliste zur IAM-Einführung: Diese Fragen sollten Sie sich bei der IAM-Implementierung stellen.