Share all details about your problem, including any error messages you may have received.
There might be scenario , where One of the conflicting access is inflight . It did not get provisioned yet , and then user raised the request for the other conflicting access from same policy.
So if it would have been in same access Request , Violation would have been generated . I know after the provisioning it will get detected .
But what if we can do the prevention then and there when user is raising the Request .
Any one have any idea about this ?
that’s definitely an interesting point you highlight.
As per my understanding the detective check would raise the violation within the next Identity Refresh as soon as both accesses are provisioned.
May I ask which kind of policy you are referring to?
As per my current understanding you should be able to analyze any inflight requests using an advanced policy.
Hi @daniel_neubert , Yes it will get detected during next refresh , But we are thinking if we can stop the user during LCM itself . Once its get detected , then violation owner might take action on that lets say after 48hr . then toxic access will still be there with user for that time duration . it might cause security breach.
Lets think from the Entitlement SOD Perspective.
I fully understand your concerns regarding the toxic access being active for a while.
That’s the reason I mentioned Advanced Policies.
There you should be able to evaluate anything which is available in the system, also inflight Access Requests etc.
Hi @daniel_neubert , Thanks for the reply . we have more than 500 policies . Now if we try with Advance SOD , We would have to convert all of them and as well as new policy in future will only be Advance SOD .
From design perspective . it does not make sense to convert all of them , and it will always be limitation .
If we can think from whole System perspective , if we can implement on environment level , Also it should work for all kind of policies . that will be more effective solution .
However, what we did in the past is creating a repository of toxic combinations, e. g. within a database table and source a single Advanced Policy to check all those toxic combinations.
I know the handling will be completely different compared to maintaining those policies in IIQ but it may solve some other issues.
