Hey all — hoping someone has run into this before I sink more time into it or wait on a support ticket.
Setup: IIQ 8.4p2
Web Services connector application (custom REST target, loosely SCIM-shaped but not fully RFC-conformant). Schema attribute groups is flagged Managed, Entitlement, Multi-Valued, type group. Backing target returns group membership as an array of objects like {"value":"6465","display":"Standard"} on GET — nothing unusual for a non-conformant SCIM implementation.
Symptom: First real access request through this app (single “Add Entitlement” for one group) provisions correctly — confirmed on the target app itself, and the Provisioning Transaction log shows committed all the way through. But the parent IdentityRequest never closes: it sits at completionStatus="Pending", executionStatus="Verifying" indefinitely.
Digging into the Identity cube via Debug, the Link’s groups attribute is stored as a raw stringified version of the target’s response object:
{"value":"6465","display":"Standard"}
instead of a flat scalar/list of IDs.
Running Group Aggregation + Account Aggregation cleans this up perfectly — Link shows a proper <List><String>6465</String></List>. But the moment Perform Identity Request Maintenance runs (with “Verify provisioning for requests?” enabled), it flips right back to the malformed Map-shaped string, and logs a Native Change Detection event for it — even though nothing changed on the target side.
What I’ve ruled out:
No Before/After Rules on Get Object, Account Aggregation, or Add Entitlement doing this transformation
No Customization Rule on the app
Response Attribute Mapping on Get Object is a clean, direct passthrough (groups → $.groups)
No persisted IdentityEntitlement row exists for this identity/app/attribute (queried directly via Debug) — so it’s not a stale cache being re-synced
Identity Refresh (with entitlement/exception refresh options on) successfully rebuilds everything clean; it’s specifically the maintenance task’s verification step that re-breaks it
This really looks like the verification logic in Perform Identity Request Maintenance does its own live connector fetch that bypasses the app’s configured Response Attribute Mapping, and writes the raw unmapped response straight onto the Link.
Questions for the group:
Has anyone seen this specific pattern — verification corrupting a multi-valued Managed+Entitlement attribute on a WS connector?
Anyone know if provisioning verification uses a different/internal fetch path than standard aggregation?
Any known workarounds short of restructuring the schema (we need to keep this attribute multi-valued) or disabling verification (hard no in our SOX environment)?
I will be opening a support case as well, but curious if this is a known quirk of WS connectors + entitlement-type multi-valued attributes on 8.4p2 specifically, or something version-specific/patchable. Happy to share more of the XML if useful.
Here is the application .xml file. I will let you know that this app was supposed to be configured via SCIM 2.0. However, the vendor despite claiming to be 100% SCIM compliant wasn’t. Therefore we had to use their SCIM API documentation while integrating the application as a WEB SERVICES application within IIQ..
The way that they gave the values back after making a call was slightly odd and there was quite a bit of customization that had to occur as a result to parse the data properly.
I had ES more or less build out this entire integration because the complexity was far greater than I’m comfortable with..
It was quite a pain to integrate from the get go.. But the other issue, is we are in very highly regulated enviornment.. Which means we have to obey SOX controls and are limited in how we can solution..
So the solution to edit the Perform Maintenance Task wouldn’t be possible for us…
@MRP4ND4 I have gone through the app xml. this is configured as web services connector but there are few things which are wrongly configured. To start with could you please update your Get Object endpoint response schema for groups attribute:
groups → $.groups[*].value
Update this and give it a try. and let us know if it address your issue or not.
Will take a look at this.. Was digging through the app and found that the disable operation isn’t working either on a leaver event. So I have to figure that out too..
I had to remove the schema’s section from the provisioning form. This was already hard coded into a few of the rules that were used and what happened was IIQ was unable to reach in and verify the schema.. Causing a endless loop in the identityRequest that would give an erroneous entitlement that didn’t exist (headerMap) and then it would generate a NCD due to this being a SOX application.
Removing the schema from the provisioning form fixed this.
In addition, there was a few typo’s in some of the rules which needed to be corrected.
Finally, @neel193 what you suggested with groups → $.groups[*].value was the final peice that needed corrected..
Kind of a culmnination of things that needed fixed.
I smoke tested everything and it’s functioning properly, and meets the business requirements.
