Custom SCIM extension attributes not sent by ISC connector on CREATE

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

When creating an account through the ISC native SCIM connector, attributes declared under the “urn:ietf:params:scim:schemas:extension:custom:2.0:User” namespace are not included in the payload sent to the target API, despite:

- The extension schema being declared in the “schemas” array

- The attributes (“codeUni”, “codePar”) being defined in the source **Provisioning Policy**

- The target API expecting the following payload structure:

{

  "schemas": [

    "urn:ietf:params:scim:schemas:core:2.0:User",

    "urn:ietf:params:scim:schemas:extension:custom:2.0:User"

  ],

  "userName": "userName",

  "name": {

    "givenName": "givenName",

    "familyName": "familyName"

  },

  "emails": [

    {

      "value": "test@email.com",

      "type": "work",

      "primary": true

    }

  ],

  "urn:ietf:params:scim:schemas:extension:custom:2.0:User": {

    "codeUni": [{ "value": "LOK009"}],

    "codePar": [{ "value": "YOP006"}]

  }

}

The connector correctly sends **core** attributes (“userName”, “name”, “emails”) but **silently drops** the custom extension block, causing the target API to return “HTTP 400”.

2

Hey @FXNOAHOWONO you need to add Before provisioning rule
Provisioning of Extended Attributes{

3

In ISC, defining the custom extension URN and adding codeUni / codePar in the provisioning policy may not be enough if the target expects them under a nested SCIM extension object during CREATE. SailPoint’s SCIM extended-attributes guidance points to using a Before Provisioning rule to modify the provisioning plan for this kind of case.

Since your target expects:


"urn:ietf:params:scim:schemas:extension:custom:2.0:User": {
"codeUni": [{ "value": "LOK009" }],
"codePar": [{ "value": "YOP006" }]
}

I would read the flat values from the provisioning policy, remove them as standalone attributes, and then add a single attribute request for the extension block with the nested structure.

Also note that these are complex multi-valued attributes, so the exact array/object shape matters. If the native SCIM connector still doesn’t serialize the extension correctly on CREATE after that, I’d consider a Web Services source for full payload control.

4

as @raghav_chouda mentioned, a Provisioning rule should be written. Reference: Provisioning of Extended Attributes

5

@raghav_chouda

You can follow the below steps

If the above steps doesn’t work then follow below

  1. Perform the GET operation on the Source via REST API , copy the entire source body

  2. Update the source using PUT method and add below piece of mapping under → schemaPropertyMappings → Under the tag → “urn”: “urn:ietf:params:scim:schemas:core:2.0:User”, below group attribute mapping and update the source using PUT.

{
“name”: “name of the field”,
“property”: “name of the field”,
“value”: null,
“getter”: “openconnector.connector.scim2.SCIM2PropertyGetter”,
“queryClass”: null,
“setter”: “openconnector.connector.scim2.SCIM2PropertySetter”,
“childAttributeMappingList”: null,
“config”: null,
“generatedBySystem”: false,
“originalXml”: null
}

  1. Check if attribute is showing under schemaPropertyMapping if yes then under create provisioning form delete the existing ‘title’ attribute and re-add it again and verify the create operation.