SCIM User Provisioning

Übersicht

In diesem Artikel werden die Fehlerbehebung und die Lösung von Problemen im Zusammenhang mit dem SCIM User Provisioning im LMS beschrieben. Er richtet sich an Support-Mitarbeiter und Administratoren, die SCIM-bezogene Probleme diagnostizieren und beheben müssen.

Was versteht man unter SCIM User Provisioning?

Beim SCIM User Provisioning übermittelt der Identity Provider Nutzerdaten über ein REST-Interface an das LMS. Unter anderem werden folgende Aufgaben durchgeführt:

• Nutzer anlegen

• Nutzer aktualisieren

• Nutzer deaktivieren

• Nutzer reaktivieren

• Gruppen- oder Organisationszuordnungen übertragen (falls konfiguriert)

Wenn ein Nutzer nicht korrekt angelegt oder aktualisiert wird, liegt die Ursache in der Regel in fehlerhaften Attributen, falschen Zuordnungen, fehlenden Pflichtfeldern, Berechtigungsproblemen oder einem ungültigen SCIM-Request.

Die Konfiguration im LMS wird in der Funktion Konfiguration über das Menü SCIM vorgenommen.

Swagger API Dokumentation

Die verfügbaren SCIM-API-Aufrufe können in der Swagger-Dokumentation des LMS eingesehen werden:

🔗 Swagger SCIM API

Dort sind unter anderem die folgenden SCIM-Endpunkte dokumentiert:

Groups-Endpunkte:

• GET /lms/scim/Groups

• POST /lms/scim/Groups

• PUT /lms/scim/Groups

• GET /lms/scim/Groups/{id}

• PATCH /lms/scim/Groups/{id}

Users-Endpunkte:

• GET /lms/scim/Users

• POST /lms/scim/Users

• POST /lms/scim/Users/.search

• GET /lms/scim/Users/{id}

• PATCH /lms/scim/Users/{id}

• PUT /lms/scim/Users/{id}

• DELETE /lms/scim/Users/{id}

Zur Überprüfung der unterstützten Endpunkte, Request-Strukturen und API-Parameter sollte die Swagger-Dokumentation herangezogen werden.

Wichtige Attribute

Die folgenden Attribute sind zentral für die SCIM-Kommunikation und häufige Fehlerquellen.

EXT_ID_SCIM

Die EXT_ID_SCIM dient häufig zur eindeutigen Zuordnung zwischen Identity Provider und LMS.

Beispiel:

"EXT_ID_SCIM": "E00000238"

Wichtig:

• Sollte eindeutig sein

• Sollte sich nachträglich nicht ändern

• Sollte nicht leer sein

• Sollte dauerhaft stabil bleiben

userName

Der userName wird häufig als Login-Name verwendet.

Beispiel:

"userName": "E00000238"

Wichtig:

• Muss eindeutig sein

• Darf nicht leer sein

• Sollte keine unerlaubten Sonderzeichen enthalten

• Sollte nicht mit bestehenden Nutzern kollidieren

emails.value

Die E-Mail-Adresse wird oft für Benachrichtigungen, Login oder zur Nutzeridentifikation verwendet.

Beispiel:

"emails": [
  {
    "value": "max.mustermann@example.com",
    "type": "work",
    "primary": true
  }
]

Wichtig:

• Sollte gültig sein

• Sollte eindeutig sein, falls als Login oder eindeutiges Feld verwendet

• Darf bei Pflichtfeldkonfiguration nicht leer sein

active

Das Feld active steuert normalerweise, ob ein Nutzer aktiv oder inaktiv ist.

Beispiel aktiv:

"active": true

Beispiel inaktiv:

"active": false

Häufige Fehlerbilder

1. Nutzer wird nicht angelegt

Mögliche Ursachen

• Pflichtattribute fehlen im SCIM-Request

• userName oder EXT_ID_SCIM ist leer oder nicht eindeutig

• E-Mail-Adresse fehlt oder ist ungültig

• Attribut-Mapping im Identity Provider ist fehlerhaft

• Nutzer ist im Identity Provider nicht der Provisioning-App zugewiesen

• SCIM-Endpunkt oder Token ist falsch

• Nutzer existiert bereits mit abweichender ID im LMS

Prüfung

Suchen Sie im Log nach folgenden Begriffen:

SCIM
provisioning
User
EXT_ID_SCIM
userName
create
POST /Users

Zusätzlich sollten Sie Folgendes prüfen:

PRS0126
LOGIN_REGISTRATION_LOGIN_FAILED_UNIQUENESS
duplicate
uniqueness
mandatory
required
validation

Typische technische Ursache

Ein häufiger Fall ist, dass der Login-Name bereits existiert oder nicht eindeutig ist. Dann kann der Nutzer nicht neu angelegt werden.

Beispiel:

LOGIN_REGISTRATION_LOGIN_FAILED_UNIQUENESS

Lösung

• Prüfen, ob userName eindeutig ist

• Prüfen, ob EXT_ID_SCIM korrekt gesetzt wird

• Prüfen, ob der Nutzer bereits im LMS existiert

• Attribut-Mapping im Identity Provider kontrollieren

• Testweise einen einzelnen Nutzer neu provisionieren

• Falls nötig, bestehende Dubletten oder fehlerhafte Nutzerzuordnungen bereinigen

2. Nutzer wird nicht aktualisiert

Mögliche Ursachen

• EXT_ID_SCIM stimmt nicht mit dem bestehenden Nutzer überein.

• Der Identity Provider sendet eine andere Nutzerkennung als beim initialen Import.

• Das Feld für die eindeutige Zuordnung wurde nachträglich geändert.

• Der Update-Request enthält ungültige oder leere Pflichtwerte.

• Der Nutzer ist im LMS gesperrt oder in einem Status, der Updates verhindert.

• Das Attribut ist im LMS nicht für SCIM-Mapping vorgesehen.

Prüfung

Suchen Sie im Log nach folgenden Begriffen:

PUT /Users
PATCH /Users
EXT_ID_SCIM
userName
SCIM update

Prüfen Sie insbesondere, ob der Nutzer anhand von EXT_ID_SCIM, userName oder einer anderen konfigurierten eindeutigen ID korrekt gefunden wird.

Lösung

• Prüfen Sie, welcher Identifier für die Nutzerzuordnung verwendet wird.

• Stellen Sie sicher, dass sich EXT_ID_SCIM nicht nachträglich geändert hat.

• Vergleichen Sie das Mapping im Identity Provider mit der Konfiguration von Scheer IMC.

• Synchronisieren Sie einen einzelnen Nutzer erneut.

• Prüfen Sie, ob das betroffene Attribut im LMS überschrieben werden darf.

3. Nutzer wird deaktiviert, obwohl er aktiv bleiben soll

Mögliche Ursachen

• Der Nutzer wurde im Identity Provider deaktiviert.

• Der Nutzer wurde aus der Provisioning-Gruppe entfernt.

• Der Scope der Provisioning-App wurde geändert.

• Der Identity Provider sendet active = false.

• Gruppenfilter oder Zuweisungen sind falsch konfiguriert.

Prüfung

Prüfen Sie im SCIM-Payload:

{
  "active": false
}

Suchen Sie im Log nach:

active
deactivate
disable
PATCH /Users

Lösung

• Prüfen Sie im Identity Provider, ob der Nutzer aktiv ist.

• Prüfen Sie, ob der Nutzer weiterhin der SCIM-App zugewiesen ist.

• Kontrollieren Sie Gruppen- und Scope-Filter.

• Prüfen Sie die Provisioning-Logs im Identity Provider.

• Provisionieren Sie den Nutzer nach der Korrektur neu.

4. Nutzer wird nicht deaktiviert

Mögliche Ursachen

• Der Identity Provider sendet keinen Deaktivierungsrequest.

• Die Deaktivierung ist in der SCIM-Konfiguration nicht aktiv.

• Der Nutzer wurde im Identity Provider gelöscht, aber nicht deaktiviert.

• Der Identity Provider unterstützt Löschung und Deaktivierung unterschiedlich.

• Das LMS interpretiert den Request nicht als Deaktivierung.

Prüfung

Prüfen Sie, ob ein Request mit folgendem Inhalt gesendet wurde:

{
  "active": false
}

Oder ob ein DELETE /Users Request verwendet wurde.

Suchen Sie im Log nach:

DELETE /Users
active false
disable
deactivate

Lösung

• Prüfen Sie, welches Verhalten der Identity Provider beim Entfernen eines Nutzers ausführt.

• Empfehlung: Lassen Sie den Nutzer über active = false deaktivieren.

• Prüfen Sie die Provisioning-Konfiguration im Identity Provider.

• Passen Sie falls nötig das Mapping oder die Deaktivierungslogik an.

5. Fehler wegen fehlender Pflichtfelder

Mögliche Ursachen

• userName fehlt.

• EXT_ID_SCIM fehlt.

• Name, E-Mail oder andere Pflichtattribute fehlen.

• Pflichtfelder sind im Identity Provider leer.

• Das Attribut-Mapping verweist auf ein nicht gefülltes Feld.

Beispiel für einen fehlerhaften Payload

{
  "userName": "",
  "EXT_ID_SCIM": "E00000238",
  "name": {
    "familyName": "",
    "givenName": ""
  },
  "emails": [
    {
      "value": "",
      "type": "work",
      "primary": true
    }
  ]
}

Bewertung

Dieser Request ist problematisch, weil mehrere wichtige Attribute leer sind. Besonders kritisch sind:

• userName

• emails.value

• name.familyName

• name.givenName

Je nach IMC-Konfiguration können diese Felder Pflichtfelder sein.

Lösung

• Befüllen Sie die Pflichtfelder im Identity Provider.

• Prüfen Sie das Mapping für Vorname, Nachname, Loginname und E-Mail.

• Stellen Sie sicher, dass keine leeren Strings übertragen werden.

• Provisionieren Sie Testnutzer mit vollständigen Attributen.

Analyse und Diagnose

Relevante Log-Begriffe

Bei SCIM-Problemen sollten Sie nach folgenden Begriffen suchen:

SCIM
Users
POST /Users
PUT /Users
PATCH /Users
DELETE /Users
EXT_ID_SCIM
userName
active
provisioning
PersonStoreProcessor
ProfileValidator
PRS0126
LOGIN_REGISTRATION_LOGIN_FAILED_UNIQUENESS

Typische Fehlerklassen

Typische Lösungswege

Fehlerhaftes Mapping korrigieren

Wenn Attribute leer oder falsch übertragen werden:

• Prüfen Sie das Mapping im Identity Provider.

• Ordnen Sie Pflichtattribute korrekt zu.

• Provisionieren Sie Testnutzer erneut.

• Prüfen Sie, ob der korrigierte Payload vollständig ist.

Dubletten bereinigen

Wenn Nutzer wegen Eindeutigkeitsverletzung nicht angelegt werden:

• Suchen Sie bestehenden Nutzer mit gleichem Login.

• Suchen Sie bestehenden Nutzer mit gleicher E-Mail.

• Prüfen Sie, ob der Nutzer bereits mit anderer EXT_ID_SCIM existiert.

• Bereinigen Sie die Dublette oder korrigieren Sie das Mapping.

Token oder Endpunkt prüfen

Bei Authentifizierungsproblemen:

• Prüfen Sie den SCIM-Token.

• Erneuern Sie den Token.

• Prüfen Sie den SCIM-Endpunkt.

• Kontrollieren Sie die Berechtigungen.

• Führen Sie eine Testverbindung im Identity Provider aus.

Nutzer erneut provisionieren

Nach Korrekturen:

• Provisionieren Sie einzelnen Nutzer im Identity Provider erneut.

• Synchronisieren Sie nicht direkt alle Nutzer neu.

• Prüfen Sie das Ergebnis im Provisioning-Log.

• Prüfen Sie danach das IMC-Log gegen.

Praxisbeispiele

Beispiel 1: Fehlende Pflichtattribute

Request

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
  ],
  "id": "E00000238",
  "EXT_ID_SCIM": "E00000238",
  "userName": "E00000238",
  "name": {
    "familyName": "",
    "givenName": ""
  },
  "displayName": "",
  "emails": [
    {
      "value": "",
      "type": "work",
      "primary": true
    }
  ]
}

Bewertung

Der Request enthält zwar EXT_ID_SCIM und userName, aber wichtige Nutzerattribute sind leer:

• familyName

• givenName

• displayName

• emails.value

Wenn diese Felder in der imc Learning Suite als Pflichtfelder erwartet werden, kann der Nutzer nicht korrekt angelegt oder aktualisiert werden.

Lösung

Der Identity Provider muss vollständige Werte senden, zum Beispiel:

{
  "EXT_ID_SCIM": "E00000238",
  "userName": "E00000238",
  "name": {
    "familyName": "Mustermann",
    "givenName": "Max"
  },
  "displayName": "Max Mustermann",
  "emails": [
    {
      "value": "max.mustermann@example.com",
      "type": "work",
      "primary": true
    }
  ],
  "active": true
}

Beispiel 2: Nicht unterstütztes Attribut

Request

{
  "schemas":
  ["urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
  "id": "EUSER0001",
  "externalId": "EUSER0001",
  "userName": "EUSER0001",
  "name": {
    "familyName": "Maxi",
    "givenName": "mum"
  },
  "displayName": "",
  "emails": [{
      "value": "",
      "type": "work",
      "primary": true
    }
  ],
  "addresses": [{
      "streetAddress": "",
      "locality": "",
      "region": "",
      "postalCode": "",
      "country": "",
      "type": "work",
      "primary": true
    }
  ],
  "ims": [{
      "value": "1",
      "type": "custom.sex"
    },
    {
      "value": "1",
      "type": "custom.auth_status"
    },
    {
      "value": "1030",
      "type": "custom.group_id"
    }
  ],
  "userType": "Employee",
  "jobCategory": "89",
  "title": "Dr.",
  "preferredLanguage": "",
  "timezone": "",
  "active": "1",
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "employeeNumber": "EUSER0001",
    "costCenter": "899",
    "organization": "IMC AG",
    "manager": {
      "value": ""
    }
  }
}

Bewertung

Fehler im Log:

02-06-2026 08:43:53.142 ERROR [http-nio-8080-exec-7] scim.SCIMUserResource [SCIMUserResource.java:248]: SCIM Error reading user Attribute jobCategory is not supported
de.imc.clix.control.exceptions.ClixException: Attribute jobCategory is not supported

Der Request enthält zwar jobCategory, allerdings ist dies kein unterstütztes Standard-SCIM-Attribut.

Lösung

Definieren Sie das Attribut jobCategory im Request und im Mapping als Custom-Attribut.

{
  "schemas":
  ["urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],
  "id": "EUSER0001",
  "externalId": "EUSER0001",
  "userName": "EUSER0001",
  "name": {
    "familyName": "Maxi",
    "givenName": "mum"
  },
  "displayName": "",
  "emails": [{
      "value": "",
      "type": "work",
      "primary": true
    }
  ],
  "addresses": [{
      "streetAddress": "",
      "locality": "",
      "region": "",
      "postalCode": "",
      "country": "",
      "type": "work",
      "primary": true
    }
  ],
  "ims": [{
      "value": "1",
      "type": "custom.sex"
    },
    {
      "value": "1",
      "type": "custom.auth_status"
    },
    {
      "value": "1030",
      "type": "custom.group_id"
    },
    {
      "value": "89",
      "type": "custom.jobCategory"
    }
  ],
  "userType": "Employee",
  "title": "Dr.",
  "preferredLanguage": "",
  "timezone": "",
  "active": "1",
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "employeeNumber": "EUSER0001",
    "costCenter": "899",
    "organization": "IMC AG",
    "manager": {
      "value": ""
    }
  }

Fehlercodes-Referenz

Die folgende Tabelle listet alle relevanten Fehlercodes und deren Bedeutung auf.

Relevante Fehlercodes und deren Bedeutung

Benötigte Informationen für ein Service Desk Ticket

Bitte stellen Sie folgende Informationen bereit:

• Kundensystem / URL

• SCIM User

• Zeitpunkt des Fehlers

• Betroffener Nutzer

• EXT_ID_SCIM

• userName

• E-Mail-Adresse

• Aktion: Create / Update / Deactivate / Delete

• HTTP Status Code

• SCIM Request Payload

• SCIM Response Payload

• Provisioning-Log aus dem Identity Provider

• Relevanter Log-Auszug

• Erwartetes Verhalten

• Tatsächliches Verhalten

Verwandte Artikel

CSV-Nutzerimport über das Backend

CSV-Nutzerimport über Nutzerimport-Planung