SCIM Single-Valued User Attribute/Entitlement: UserType - How to "flip" assignment

Which IIQ version are you inquiring about?

*8.*4p3

Share all details about your problem, including any error messages you may have received.

*We are integrating two applications that support SCIM but are not fully SCIM compliant. To mitigate some short-comings, we leverage the “Web Services Connector”.

Both applications manage the user license via the SCIM attribute “userType”. We have configured the schema attribute like this:*
<AttributeDefinition entitlement="true" managed="true" name="userType" type="string"/>

However, IIQ seems to handle this attribute not as single-value. If a user requests a different userType, IIQ provisions and stores the newly requested value but keeps the existing AttributeAssignment. As a result, the user has two userType entitlements and one of them is missing on the account. Each identity refresh will re-provision the missing assignment and overwrite the existing on. Needless to say, this will become an endless loop.

What is the best practice to handle such single-valued attribute assignments and ensure that only one entitlement is assigned?

Hi @vonschwc ,

I haven’t worked much on SCIM, just want to check how provisioning plan is created.

For attribute request, which operation is used, “Add” or “Set”?

Can you try with “Set” operation for attribute assignment in Provisioning plan and see what is outcome.

can you add multivalued =“false” from debug like below?? and also

After updating the schema, also ensure user doesn’t have stale AttributeAssignment entries. Run a refresh task with Refresh Identity Entitlements enabled after the change to reconcile existing identities cleanly.

Thank you for your advice!
Currently we are using the “Add Entitlement” operation and were trying to implement a Before rule that will add a “Remove” (old attribute) to the provisioning plan. However, replacing (Set) the value is the much more elegant way. I’ll give this a try.

Thank you for your advice!

I will explicitly set multi=false directly in debug and see if this changes the operation to “Set”.

did you try and did it work??

@vonschwc No need to set multi=“false” explicitly , if its not available on the schema attribute, IIQ consider it as single value attribute.
This is the default behaviour of AttributeAssignment. If it is a single value attribute, you are basically doing a Add operation only in both case, there is no remove operation for previous entitlement. That;s why AttributeAssignment is not able to clear it and next identity refresh re provision it.
Please introduce a before provisioning rule, add the remove entitlement account request as well to remove the old entitlement, and let the add account request to add the new entitlement. In this way, attribute assignment will be cleaned up properly.

@vonschwc Alternatively, if its a common behaviour for most of your apps, you can handle this in your LCM provisioning as well.