Die Integration zwischen der SAP- und der Microsoft-Welt ist nach wie vor eine Aufgabe, die nicht so einfach zu bewältigen ist. Damit haben wir uns bereits in einem früheren Blogbeitrag beschäftigt. Besonders deutlich wird die Herausforderung der Integration beim Abgleich von Benutzerdaten zum Aufbau einer gemeinsamen Benutzerbasis, die für ein nahtloses Arbeiten mit den korrekten Berechtigungen zwingend vorhanden sein muss. Wie lässt sich eine gemeinsame Nutzerbasis zwischen SAP- und Microsoft-Systemen in der Cloud automatisiert gewährleisten? SAP hat dafür den SAP Identity Provisioning Service (IPS) etabliert.
Der Identity Provisioning Service der SAP Cloud Platform, 2016 ins Leben gerufen, automatisiert Identitäts-Lebenszyklus-Prozesse. Er hilft dabei, Identitäten und deren Berechtigungen für verschiedene Cloud- und On-Premise-Geschäftsanwendungen zu provisionieren. Auch in Single-Sign-On- und Governance-Mikrodienste ist er integriert, zum Beispiel in den SAP Identity Authentication Service (IAS) und in SAP Cloud Identity Access Governance (IAG). Während sich der IAS um eine systemübergreifende, SAML2-konforme Authentifizierung kümmert, wird IAG für Risikoprüfungen in der Cloud verwendet.
Der Identity Provisioning Service gehört zur Neo-Umgebung der SAP Cloud Platform und wird in verschiedenen Regionen gehostet. Er erfüllt unter anderem folgende Aufgaben:
Um Workflows und Genehmigungen zu prozessieren oder eine tiefergehende Logik zu implementieren, lässt sich der IPS hingegen nicht verwenden. Diese Funktionalitäten deckt weiterhin SAP Identity Management (IdM) on-premise ab.
Benutzer und Gruppen können zwischen verschiedenen Geschäftsanwendungen provisioniert werden, die als Quell- und Zielsysteme definierbar sind. Mithilfe eines Proxy-Konnektors lassen sich auch Identitäten von einem SCIM-basierten System zu einem Nicht-SCIM-System provisionieren. Die Liste der Systeme wird stetig erweitert, der aktuelle Stand ist hier abrufbar. Für die Konfiguration der Systeme stehen umfangreiche Einstellungsmöglichkeiten und Filtereigenschaften zur Verfügung.
Die Standard-System-Transformationen sind direkt nutzbar oder an die Geschäftsanforderungen anpassbar. Dabei können Attribut-Transformationen sowohl auf dem Quellsystem als auch auf dem Zielsystem adaptiert werden. Oder sie müssen in Einklang gebracht werden, um Quellattribute im richtigen Format an die richtigen Zielattribute zu schreiben. Das geschieht mittels JSON Schema Deklaration.
Provisionierungsjobs lassen sich manuell ausführen oder in einem bestimmten Zeitintervall für automatische Ausführungen einplanen. Dabei steht ein vollständiger oder synchronisierter Leseauftrag zur Auswahl. Der Synchronisierungsjob liest und provisioniert nur die neuen und aktualisierten Entitäten, da mithilfe eines Delta-Mechanismus berechnet wird, welche Änderungen angefallen sind.
Wurde ein Job nicht erfolgreich abgeschlossen, lassen sich dessen Protokolle direkt in der Benutzeroberfläche anzeigen und herunterladen. Die Protokolle informieren darüber, welche Entitäten fehlgeschlagen sind und warum. Es ist auch möglich, ein Quellsystem zu abonnieren, um per E-Mail benachrichtigt zu werden, wenn ein Auftrag fehlgeschlagen ist.
Dieses Szenario eignet sich für anfängliche, regelmäßige und geplante Lese- und Synchronisierungsjobs aller Identitäten von jedem unterstützten Quellsystem zu jedem Zielsystem. Dabei können immer ein oder mehrere Quellsysteme auf Änderungen eines Zielsystems reagieren.
Als Quellsystem fungiert normalerweise das vorhandene User Directory des Unternehmens, etwa die zentrale Benutzerverwaltung von AS ABAP oder Microsoft Active Directory. Es kann sich dabei sowohl um ein Cloud- als auch um ein On-Premise-System handeln. Das Zielsystem ist ein Cloud- oder On-Premise-System, das mit Entitäten aus dem Quellsystem gefüllt werden soll. Dafür ist das Starten eines Provisionierungsjobs erforderlich.
Es ist möglich, Entitäten aus dem IAS sofort für jedes Zielsystem zu provisionieren, ohne einen manuellen oder geplanten Job abzustoßen. Mit der Echtzeit-Provisionierung können neu erstellte oder aktualisierte Benutzer verteilt werden, ohne dass ein Job manuell ausgeführt oder auf einen geplanten Job gewartet werden muss.
Diese Funktion ist praktisch bei Szenarien, die eine synchrone Provisionierung und einen sofortigen Systemzugriff erfordern, zum Beispiel die Selbstregistrierung von Benutzern. Auch für einzelne oder mehrere Entitäten, die in der Administrationskonsole des IAS oder über dessen SCIM API neu erstellt und sofort für jedes unterstützte Zielsystem synchronisiert werden sollen, kann die Funktion genutzt werden. Das Starten eines Provisionierungsjobs ist dafür nicht erforderlich.
Der Proxy-Modus ist ein spezieller Konnektor-Typ für hybride Szenarien. Das heißt, es lassen sich Entitäten von einem SCIM-basierten System zu einem anderen externen System, das nicht auf SCIM basiert, provisionieren, ohne eine direkte Verbindung zwischen den Systemen herstellen zu müssen. Um dies zu erreichen, wird ein Identity-Provisioning-Proxy-Konnektor hinzugefügt, der die Rolle eines SCIM 2.0 Endpoint spielt und die jeweilige API des angeschlossenen Systems nutzt.
SAP Identity Management (IdM) on-premise kann diesen Proxy-Konnektor mittels Import-Funktionalität direkt verwenden. Dafür muss die Konfiguration des Systems im IPS heruntergeladen und in SAP IdM als neues Repository importiert werden. Danach können Initial Load Jobs für dieses System in SAP IdM ausgeführt werden, um das System einzulesen. Anschließend ist das System in SAP IdM wie andere Systemtypen nutzbar.
Das lokale Identitätsverzeichnis ist Teil des SAP IPS und bietet Organisationen ein Verzeichnis zum Speichern und Verwalten von Benutzern und Gruppen auf der SAP Business Technology Platform. Leider ist es nicht möglich, in diesem System über Benutzeroberflächen Daten einzusehen oder Änderungen an den Daten durchzuführen.
Der erste Schritt ist die Erstellung eines Application Client mit lesender Berechtigung in Microsoft Azure AD. Im IPS wird Microsoft Azure AD als neues Quellsystem ausgewählt und der Application Client sowie weitere Parameter werden in die Systemeinstellungen eingetragen. Im Transformationsschema lassen sich Mappings zwischen Attributen des Microsoft Azure AD und SAP IPS durchführen.
Daten aus dem Quellsystem – etwa Benutzerdaten – in die SAP Cloud Platform als Member schreiben zu können, erfordert das Anlegen eines Zielsystems für diesen Systemtyp. Als Quelle für das Zielsystem wird das zuvor angelegte Microsoft Azure AD ausgewählt.
Auch für die SAP Cloud Platform ist ein Application Client mit den korrekten Berechtigungen anzulegen. Er wird in den Systemeinstellungen neben weiteren Kommunikationsparametern eingetragen. Im Transformationsschema müssen die Mappings der Attribute des SAP IPS und der SAP Cloud Platform entsprechend angepasst werden.
Die Synchronisation beginnt mit dem manuellen Starten eines Sync Jobs im Quellsystem. Dieser kann nach erfolgreicher Abarbeitung auch eingeplant werden. Im Job Log lassen sich die erfolgreich übertragenen Daten überblicken und etwaige Fehler einsehen.
Aktuell ist es mit dem SAP Identity Provisioning Service (IPS) möglich, Datensynchronisationen zwischen Systemen durchzuführen. Workflows für Rollenzuordnungen können hingegen nicht implementiert werden. Dies gelingt nur mithilfe der IPS-Proxy-Funktionalität und einem SAP Identity Management on-premise in einem hybriden Szenario. Perspektivisch werden die bestehenden SAP Cloud Services wie IAS und IAG enger mit dem IPS zusammenwachsen.