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?
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.
@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.