SCIM 2.0: Standardisierte Benutzerverwaltung in der Cloud
Immer mehr Unternehmen entscheiden sich dafür, Ihre Daten, Anwendungen oder andere Business-Elemente von Ihren lokalen Systemen in die Cloud zu migrieren. Hierbei handelt es sich bei Cloud-Systemen um die Software, die bei einem externen IT-Dienstleister (Host) betrieben und von Kunden als Dienstleistung verwendet wird. Zusammen mit der Einführung von unterschiedlichen Lösungen steigt ebenfalls die Anzahl von Benutzer-Accounts, die verwaltet werden müssen. Die Synchronisierung von Benutzeridentitäten und Ihren Berechtigungen über mehrere, unterschiedliche Systeme hinweg war schon immer eine Herausforderung für jede Organisation. Wie können nun die Risiken in dem komplexen, exponentiell wachsenden Umfeld minimiert werden?
SCIM steht für System-Cross Domain Identity Management und wurde entwickelt, um die Benutzerverwaltung in dynamischen und sich schnell verändernden Infrastrukturen zu vereinfachen. Das unter Internet Engineering Task Force (IETF) veröffentlichte Protokoll liefert ein standardisiertes Schema für Benutzer und Gruppen sowie auch RESTful APIs, die CRUD*-Operationen auf den SCIM-Ressourcen ermöglichen.
* CRUD = Create, Read, Update, Delete
Inhaltsverzeichnis
High-Level-Konzept
SCIM basiert auf einem Objektmodell, in dem das Ressource-Objekt das Basisobjekt darstellt und weitere Objekte wie Benutzer, Gruppen usw. davon abgeleitet sind. Nachfolgend finden Sie eine graphische Darstellung des SCIM-Modells im UML-Format. Eine detaillierte Beschreibung des SCIM-Schemas finden Sie im Dokument RFC 7643.
Wie funktioniert SCIM?
SCIM ist ein HTTP basiertes Protokoll, dass nach dem Client-Server Prinzip funktioniert, in dem JSON Payloads ausgetauscht werden. Unter dem SCIM-Client versteht sich der Identity Provider (IDP), wie zum Beispiel das SAP Identity Management System oder das SAP IAG, das die Rolle des Single Point of Truth (SPOT) für die Identitäten in einer Organisation übernimmt. Von dem IDP werden die Informationen weiter an die Service Provider (SP), also Cloud-basierte Anwendungen wie zum Beispiel SAP Analytics Cloud oder Microsoft Azure, provisioniert, oder von dort abgefragt. Somit können die Identity Life-Cycle relevante Prozesse wie Eintritt, Änderung einer Identität, Übertritt, Austritt usw. automatisch, sicher und transparent von einem zentralen Identity-Management-System in den Cloud-Systemen unterstützt werden.
SCIM-Endpunkte und HTTP-Methoden
Im Dokument RFC 7644 finden Sie die Methoden und Endpunkte, die in der SCIM-Spezifikation definiert sind. Jeweilige Abweichungen vom Standard oder Erweiterungen sind direkt bei SaaS-Anbietern in den jeweiligen technischen Dokumentationen des SCIM Endpoints zu prüfen.
Nachstehend finden Sie eine Beschreibung von den unterstützten HTTP Methoden sowie auch Ressourcen, die im SCIM-Standard verfügbar sind.
*Self bezieht sich auf den Benutzer, der eine authentifizierte Session mit dem Service Provider offen hat und den Endpunkt /Me aufruft.
Methoden für Authentifizierung und Autorisierung
Im SCIM werden unterschiedliche Methoden für die Authentifizierung und Autorisierung unterstützt. Zu den wichtigsten gehören:
- Mutual Authentication: In der Methode werden im TLS-Handshake beide, in der Kommunikation beteiligte, Parteien durch die entsprechende Client- und Server-Zertifikate gegenseitig authentifiziert.
- Bearer Tokens: Sind ein Bestandteil des OAuth2.0 Authorization Frameworks, in dem der Zugriff auf die geschützten Ressourcen durch die Tokens gewährleistet ist, die für den Client von dem Authentifizierungsserver herausgestellt worden sind.
- Basic Authentication: Für die Authentifizierung an einem SCIM-Endpunkt wird eine Benutzer ID und Passwort benötigt.
Weitere Authentifizierungsmethoden, die im SCIM ebenfalls supportet werden, finden Sie hier. In der Praxis wird am häufigsten das OAuth2.0 mit Bearer Tokens implementiert.
Wie teste ich einen SCIM-Endpunkt?
Um einen SCIM-Endpunkt zu testen wird ein beliebiger REST-Client benötigt. In diesem Blog werden Beispiele gezeigt, wie man über den /Groups Endpoint eine neue Gruppe anlegen kann und wie man danach die Daten angelegter Ressource abfragen kann. Für die Beispiele werden die SCIM-Endpunkte von SAP Identity Authentication Service sowie auch das REST Client verwendet.
Bedeutung für die SAP-Welt
Wenn Sie bereits ein SAP IDM 8.0 On-Premise nutzen, können Sie auch Cloud-Systeme anschließen. Diese werden über das SAP Identity Provisioning Service (IPS) für die Provisionierung zur Verfügung gestellt. Die Verbindung zwischen SAP IDM und SAP IPS wird mithilfe des SCIM-Konnektors erstellt, der standardmässig im SAP IDM 8.0 vorhanden ist. Dieses Szenario, in dem Ihr bestehendes SAP IDM System weiterhin die Rolle des zentralen Datenlieferantes übernimmt, wird auch als hybride Lösung bezeichnet. Wenn Sie sich für eine reine Cloud-Lösung entscheiden wollen, können Sie beispielsweise das SAP IAS als Identity Provider nutzen. Eine Erklärung und detaillierte Informationen von den erwähnten Tools finden Sie im Blog meines Kollegen Steffen Schatto unter folgendem Link.
Fazit
Durch den SCIM-Standard erhalten die Kunden einen Plug&Play Konnektor für alle Cloud-basierten Anwendungen, die den Standard unterstützen. Somit können Sie die neuen Systeme in Ihr bestehendes Identity Management System einbinden. Die bereits entwickelten Benutzer-Life-Cycle-Prozesse können dadurch in die neuen Systeme kosteneffizient integriert werden und deren Vorteile, wie minimiertes Compliance-Risiko durch die Transparenz über die Benutzerkonten und deren Zugriffsrechte genutzt werden.
Sie möchten Cloud-Systeme in Ihre aktuelle IT-Infrastruktur integrieren und benötigen dazu Unterstützung in Bereichen SAP IDM, SCIM, SAP IAS oder SAP IPS? Oder haben Sie vielleicht Anwendungsfälle, die Sie mit uns besprechen möchten? Kontaktieren Sie uns unter [email protected]. Wir helfen Ihnen gerne weiter.
Den spannenden, zweiteiligen Blog meines Kollegen Steffen Schatto zur Abgrenzung zwischen IDM, IPS und IAS finden Sie hier.
FAQ
Bei der Anlage einer Ressource wird in den meisten Systemen eine eindeutige ID vom Typ UUID automatisch generiert. Wenn man eine neue Ressource über die PUT-Methode anlegen würde, müsste man im Request URI die UUID mitgeben: https://example-service-provider.ch/{version}/{resource}/{id}. Dies würde zusätzliche Komplexität im SAP Identity-Management-System verursachen oder könnte zu einem unerwünschten Verhalten führen. Im Gegensatz dazu wird bei der Nutzung der POST-Methode für die Anlage einer Ressource die eindeutige ID direkt im Zielsystem generiert und im Response Body zurück an den SCIM-Client übergeben. Dieser Wert kann beispielsweise im SAP Identity Management als Account Attribut für das entsprechende System verwendet werden.
