SCIM - System for Cross-Domain Identity Management

SCIM steht für „System for Cross-Domain Identity Management“ und beschreibt eine API, wie Systeme in anderen Systemen z.B. Benutzer verwalten können und insbesondere mit AzureAD eine größere Bedeutung gewinnt.

Umfeld

Nicht alle Services und Dienste greifen nativ auf die NT-Domain oder Active Directory zu. Während OnPremises viele Server einfach Domainmitglied sind und der WinBind oder LDAP oder Kerberos sich benötigte Informationen vom Domaincontroller besorgen, sind einzeln stehende Systeme oder SaaS-Lösungen in der Cloud auf eine eigene Benutzerdatenbank mit Authentifizierung angewiesen. Dann gibt es immer eine Schnittstelle, mit der ein Administrator entsprechende Benutzer mit Anmeldeinformationen anlegen kann.

SCIM kann hier eine Lösung sein, wie die automatisch Identitäten aus einem zentralen System in diese Plattformen verwalten. Auf mehreren Seiten der MSXFAQ kommt ich immer wieder das Thema "Provisioning" zu sprechen, d.h. die strukturierte Anlage und Verwaltung von Identitäten in Firmen. Das geht manuell per AD Users&Computers, oder per Skript oder auch mit Verwaltungslösungen wie Adaxes und anderen. Größere Firmen nutzen Sync Engines, die Identitäten zwischen dem HR-System (Personalverwaltung), Active Directory und weiteren Applikationen abgleicht. Auch das Microsoft 365 Identity Management nutzt ADSync / AADConnect. Genutzte Schnittstellen sind hier LDAP (Active Directory), Microsoft Graph (Graph und Benutzer) oder auch Azure PowerShell (Microsoft 365) und Exchange OnPremises natürlich mit der Exchange PowerShell. Und all die anderen 3rd Party-Produkte haben wieder eigene proprietäre Schnittstellen, von denen viele auch nicht "Internet/SaaS"-tauglich sind.

Speziell in der Cloud ist es aber nicht mehr ausreichend, wenn sich ein Anwender per OAUTH und Token an einem anderen Service anmelden kann. Der andere Service brauch auch die Information über die Identity. Sicher gibt es Lösungen, die beim ersten Zugriff mit einem Graph Token dynamisch den Benutzer anlegen können aber wann löschen Sie so ein Konto und wie gehen sie mit Umbenennungen und Umzügen um?

Einige Produkte (z.B. auch NoSpamProxy) haben daher schon früh eigene Bestandteile bereitgestellt, um z.B. die Benutzer und Mailadressen, Rufnummern, Faxnummer etc. aus einem vorhandenen Verzeichnisdienste (Active Directory, AzureAD) regelmäßig auszulesen und auf Änderungen zu pollen. Schön ist das aber nicht, wenn das Zielsystem auf die Quelle zugreifen muss, da Authentifizierung und TCP-Verbindung kritisch sind. Würden Sie ihre Active Directory aus dem Internet "erreichbar" machen, damit eine SaaS-Lösung die Stammdaten bekommt?. Eher nicht und sie würden eher lokal einen Service installieren, der die Daten vorgefiltert nach extern sendet. Aber wollen Sie für jede SaaS-Lösung einen eigenen Agenten betreiben?

Vielleicht sagen Sie nun: SCIM habe ich noch nie gehört, das nutzt doch keiner, das ist nur was für ganz große Firmen. Dann schauen Sie sich mal die Liste der verfügbaren SaaS-Dienste auf https://aka.ms/SCIMSpec an, die schon per SCIM ein Provisioning erlauben:

Sobald ihre Identitäten auch im AzureAD vorhanden sind, können Sie all diese Applikationen ebenfalls verwalten. Aber auch wenn SCIM in der Cloud die große Verbreitung hat, hindert sie niemand die gleiche API auch OnPremises zu nutzen. Vielleicht habe ich nun ihr Interesse geweckt?

Microsoft war sehr früh mit SCIM dabei und Der Azure AD Provisioning Service unterstützt im Jahr 2022 alle Versionen (SCIM V1.0. V2.0 und V2.1)

SCIM Funktion

Hier kommt dann SCIM ins Spiel, welches sogar schon 2012 als RFC-Draft (https://datatracker.ietf.org/doc/html/draft-ietf-scim-api-00) von Mitarbeitern der Firmen Oracle, Cisco, Salesforce, SailPoint und Nexus veröffentlicht und 2015 als RFC unter weiterer Mithilfe von Microsoft und Alibaba zu einem Standard erklärt wurde. Technisch besteht SCIM aus mehreren Aktoren:

  • Ziele/Server: Cloud Service Provider (CSP)
    Er stellt einen Dienst bereit und möchte dazu die Identitäten erhalten.
  • Client/ Quelle: ihre bestehende autoritative Quelle
    Das kann ein Identity Management System oder ein bestehender Verzeichnisdienst sein

Die Kommunikation zwischen den Diensten erfolgt per HTTPS. Für den SaaS-Provider (CSP) ist das kein Problem, da er ja auch seine Dienste für die Anwender über die Cloud in der Regel per HTTPS bereitstellt. Der Payload ist JSON-formatiert und folgt einer vorgegebenen Struktur.

Der Benutzer hat eine verwaltete Identität, von der einige Informationen auch beim SaaS-Anbieter gepflegt werden sollen. Der SaaS Anbieter stellt dazu eine URL mit einigen Endpunkten samt Authentifizierung (TLS-Zertifikate, Bearer, OAUTH, Basic, Token u.a. siehe https://datatracker.ietf.org/doc/html/rfc7644#section-2 ) bereit , die ich bei dem Identity-Provider entsprechend konfigurieren muss. Laut RFC führen dann folgende Änderungen einer Identität zu einer Aktion:

  • Create
    Ein Objekt wird in der Quelle angelegt
  • Update
    Ein Objekt wird in der Quelle verändert
  • Delete
    Ein Objekt wird in der Quelle gelöscht
  • SingleSignOn
    Dies ist ein Sonderfall, dass sich ein User anmeldet und dadurch ein Create erzeugt wird.

Die API selbst kennt bei den meisten SCIM-Servern folgende Endpunkte URLs

/ServiceProviderConfig
/Schemas
/Users
/Groups
/Me
/ResourceTypes
/Bulk
/Search

Nicht alle SCIM-Services müssen alle Endpunkte anbieten und je nach Anwendungsfall kommen verschiedene Verben zum Einsatz:

  • GET = Daten abrufen
  • POST = Einträge anlegen und ändern
  • PUT / PATCH = Einträge ändern
  • DELETE = Einträge löschen

Ein HTTP-Post zum Anlegen eines Benutzers per SCIM auf einem entsprechend kompatiblen System könnte dann wie folgt aussehen:

POST /Users  HTTP/1.1
Host: scim.msxfaq.de
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer xxxxxxxxx
Content-Length: ...

   {
     "schemas":["urn:ietf:params:scim:schemas:core:2.0:User"],
     "userName":"User1",
     "externalId":"User1",
     "name":{
       "formatted":"User1 Displayname",
       "familyName":"User1FamilyName",
       "givenName":"User1givenName"
     }
   }

Die andere Seiten meldet dann ein 200 OK und ggfls. weitere Daten. Microsoft hat dazu ein schönes Tutorial geschrieben

SCIM in AzureAD

Schon das Tutorial von Microsoft zeigt, dass das AzureAD über SCIM die Identitäten auch in anderen Systemen verwalten kann. Der Azure Administrator findet das auch im Azure Portal. Jede externe SaaS-Anwendung muss natürlich als "Enterprise Application" im Azure Portal hinterlegt werden. Über den Weg kann ich als Administrator steuern, welche Benutzer die Applikation oder den SaaS-Service nutzen dürfen und welche Berechtigungen die App auf das AzureAD bekommt.

Ich habe noch keinen Hinweis gefunden, dass das AzureAD selbst eine SCIM-API bereitstellt, und ADSync scheint auch einen eigenen WebService zu nutzen, der nicht SCIM ist. Das ist aber auc zu erwarten, da SCIM eher ein "gemeinsamer Nenner" ist aber vielleicht nicht alle Optionen unterstützt.

Der SaaS-Anbieter muss dazu seine App im Azure veröffentlichen und dabei auch angeben, dass er SCIM unterstützt. Ob dies passiert ist, sehen Sie schon beim Hinzufügen der App in Azure ersichtlich

Achten Sie einfach auf das kleine "Provisioning-Icon" bei der jeweiligen App. Einige Apps wie z:B. Google hat Microsoft selbst bereit gestellt. Diese Funktion können Sie aber für eigene Dienste verwenden.

Ein guter Einstiegspunkt sind die Anleitungen von Microsoft zur Einbindung dieser Applikationen ins Provisioning.

Klicken sie dann Links auf den Bereich "User provisioning tutorials" und suchen sie die passende Lösung.

Die Liste wird kontinuierlich länger. Wenn Sie einen SaaS-Service nutzen, der hier oder in der App Gallery noch nicht erscheint, dann sollten Sie den Anbieter einfach mal auf SCIM ansprechen.

Microsoft empfiehlt, das Sie immer die Azure AD Gallery nutzen, wenn der SaaS-Hersteller dort gelistet wird. Wenn Sie eine eigene App anlegen wollen, müssen Sie eine AzureAD P1-Lizenz für ihre Anwender haben. Die meisten Firmen haben dies heute sowieso im Rahmen von EMS E3 (Intune, Conditional Access, AzureAD App Proxy) oder Microsoft 365.

Stellen Sie sich vor, sie schreiben einen kleinen Webservice als Azure Function o.ä., der alle SCIM-Requests einfach annimmt und als "Änderungsprotokoll" niederschreibt.

Wenn Sie eine kompatible App installiert haben, dann können sie in Bereich "Enterprise Apps" unter "Provisioning" die Konfiguration entsprechend anpassen. Ich stelle das Provisioning erst von "Manual" auf "Automatic" und je nach Konfiguration des Service kann ich dann einfach die Admin-Zugangsdaten oder andere Anmeldeverfahren konfigurieren. DocuSign fragt mich als Bespiel nach den Admin-Credentials während Cisco WebEx die Eingabe einer TenantURL und eines "Secret Token" anfordert.

Die Daten werden dann im AzureAD hinterlegt und durch den SCIM-Client beim Zugriff auf den SCIM-Service verwendet.

Hinweis: Pflegen Sie in der App die berechtigten "Users and Groups", damit auch nur diese Personen per SCIM publiziert werden. Sie können in der App unter "Properties" zusätzlich die Funktion "Assingment required" auf "Yes" stellen, damit Benutzer sich nicht selbst eintragen können.

Diese Einstellungen haben nichts direkt mit der Authentifizierung zu tun aber natürlich muss die SaaS-Lösung ja ihre Anwender kennen, damit diese den SaaS-Dienst nutzen können. Daher isst es anzuraten, dass Sie zuerst das Provisioning konfigurieren.

Im Hintergrund ist aber nicht das AzureAD der aktive Part sondern der "Azure AD User Provisioning Service"

Der Service bekommt die Änderungen im AzureAD über die Graph-API an einen Graph-Connector gemeldet und die Sync Engine übernimmt dann die Daten und sendet diese an das Ziel-System. Über die Konfiguration der Sync Engine können Sie auch auf die einzelnen Attribute zugreifen:

What is user provisioning in Azure Active Directory?
https://www.youtube.com/watch?v=_ZjARPpI6NI

Take your apps to the next level with provisioning from Azure Active Directory (50 Min)
https://www.youtube.com/watch?v=HRTiHt0nIHE

SCIM mit lokalem AD

Die meisten Firmen haben immer noch ein lokales Active Directory und in Verbindung mit Exchange Hybrid muss auch ADSync deployed werden. Dann sieht die Kette wie folgt aus:

Ich verwalte die Anwender im lokalen Active Directory und ADSync repliziert diese Konten in die Cloud. Diese Änderungen triggern dann den Azure AD Provisioning Service an, der die Änderungen in die angeschlossenen SaaS-Applikationen weiterreicht. Nun finden sich aber in den Tutorials auch andere Lösungen und Bilder, die ich sehr interessant finde, z.B.:


Quelle: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/sap-successfactors-inbound-provisioning-tutorial

Das Bild beschreibt, wie man mit der SaaS-Lösung "SAP SuccessFactors" zur Verwaltung von Mitarbeitern über den Azure AD Provisioning Service und einem lokalen Agenten sogar Benutzer im lokalen AD anlegen kann. Wer dann etwas nach dem Service sucht, landet direkt bei der Funktion AzureAD Cloud Sync. was genau genommen ein ADSync ist, der aber nicht lokal installiert sondern in der Cloud bereitgestellt wird und mit einem lokalen Agenten kommuniziert.

Achtung: AzureAD Cloud Sync unterstützt aktuell weder Exchange Hybrid Writeback noch Device Sync. Daher ist dies noch keine Lösung für alle Firmen.

Aber ich bin sicher, dass Microsoft auch das noch gelöst bekommt, so dass man vielleicht wirklich über den Azure AD Connect Provisioning Agent aus der Cloud heraus die lokalen Benutzer und Gruppen verwalten kann.

Der "Azure AD Connect Provisioning Agent" ist aber kein SCIM-Agent, der aus dem Internet erreichbar sein muss. Der Agent baut die Verbindung ausgehende per HTTPS zum Provisioning Service auf.

Bislang habe ich noch keinen SCIM-Agenten für das lokale AD gefunden. Das wäre ja schon nett, wenn Identity Management Systeme über SCIM auch im lokalen AD arbeiten könnte. Auch das AzureAD selbst ist anscheinend kein SCIM-Server sondern kann nur andere Server ansprechen. Wer also Identitäten in AzureAD verwalten will, muss das er Graph oder AzureAD PowerShell machen.

Kennworte mit SCIM

Wenn ich jede Änderung im AzureAD per SCIM an nachrangige Dienste übertragen kann, dann stellt sich natürlich die Frage, ob das auch Kennworte betreffen kann. Klassischerweise müssen und sollten die abhängigen Dienste natürlich kein Kennwort bekommen, wenn Sie OAUTH/SAML unterstützten. Der Client kommt dann einfach mit einem Bearer-Token, welches vom AzureAD ausgestellt wurde.

Es kann aber durchaus Services mit Clients geben, die kein OAUTH unterstützten. Dann wäre es ja eine Möglichkeit, dass Kennwort in den entsprechenden Systemen zu setzen. Zwei Optionen kann ich sind mir vorstellen:

  • Password Sync
    Bei einem "Password Sync" muss in der Quelle das Kennwort in einer Form vorliegen, mit der das Ziel auch umgehen kann. Bei ADSync wird nicht das Kennwort sondern nur der Hash eines vorhanden Hash bei Password Hash Sync (PHS) übertragen aber kein Klartext-Kennwort. Der Anwender kann aber weiterhin seine bekannten Wege zur Änderung des Kennworts nutzen.
  • Password Updates
    Alternativ könnte der Anwender sein Kennwort über eine speziell bereitgestellte App ändern, welche dann natürlich für kurze Zeit das Klartext-Kennwort kennt und auf den verbundenen Systemen ändert. Das muss natürlich ausreichend "sicher" gemacht werden, damit die Daten nicht ausgeleitet aber auch zuverlässig auf allen Diensten aktualisiert werden

SCIM beschreibt eine API, mit der Benutzer nicht nur angelegt sondern auch geändert werden können. Über den Weg kann auch ein Kennwort gesetzt werden.

Dennoch würde ich lieber alles daran setzen, dass die Anmeldung per Tokens (SAML) erfolgt, so dass die kritischen Zugangsdaten wirklich nur beim zentralen Authentifizierungsservice, z.B. AzureAD geprüft werden und dann ein Ticket für den Zugriff auf den Service ausgestellt wird.

Weitere Links