Hi all,
I’m looking for opinions and war stories on a design problem, not a specific bug.
Setup: ISC with an HRIS (Zoho People) as the authoritative source. Identity attributes such as department and business entity drive role assignment, and roles drive entitlements in downstream targets (Atlassian, GitHub, Google Workspace, and others). Aggregation → identity refresh → role recalculation → provisioning is fully automated, as intended.
What happened: the HRIS did not go down and the API did not error. It answered normally — but the department data on its side was corrupted for a portion of the population. ISC did exactly what it was configured to do: it trusted the source, recalculated roles, and revoked entitlements for several hundred employees, which translated into tens of thousands of provisioning calls to targets in a very short window. From a monitoring standpoint everything was “green”; the failure was in the content of a healthy response, not in availability.
The problem I want to solve: ISC currently applies whatever the authoritative source says with full trust. I’d like to introduce a “trust, but verify in specific cases” layer — a way for the platform to recognise an implausible bulk change in incoming data and not propagate it to access automatically, or at least to bound how much damage it can do before a human looks at it.
What I’ve considered so far:
- Circuit breaker on volume. Measure provisioning operations per unit of time (revokes counted separately) and stop the pipeline — e.g. shut down the VA — when a threshold is breached. Caps blast radius, but reacts after the first wave has already gone out, and the detection latency depends entirely on how fast you can observe the counter.
- Staging / review before provisioning. Hold recalculated access in a pending state and require approval when the change set exceeds N identities or N% of the population. Safest, but pushes toil onto the IAM team and slows down legitimate mass changes (reorgs, M&A).
- Snapshot and rollback. Keep a known-good state of identity attributes / role assignments and be able to restore it. Doesn’t prevent anything, but turns a multi-day manual recovery into a controlled operation.
Questions for the community:
- Is there anything native in ISC for this that I’m missing? Something like a sanity/threshold check on aggregation (e.g. “abort if more than X% of accounts changed a given attribute”, similar in spirit to the optimized-aggregation and account-delete-threshold protections), or a guard specifically on the provisioning side rather than the aggregation side?
- Has anyone implemented a pre-provisioning guard using Identity Attribute transforms, Identity Profile logic, or an intermediate attribute — e.g. holding the previous value and refusing to accept a new one when it fails a plausibility rule?
- Are there sensible patterns for detecting this via the Search API / Event Triggers (Identity Attribute Changed, Account Aggregation Completed) fast enough to be useful, and for programmatically pausing the pipeline from a trigger?
- More broadly: has anyone genuinely solved the “authoritative source lies to you” problem, or is the accepted answer that data quality is the HRIS owner’s responsibility and IGA should only invest in fast rollback?
Interested in any experience here, including “we tried X and it caused more problems than it solved.”
Thanks.