Any Idea about Inflight access Request SOD?

Which IIQ version are you inquiring about?

8.x

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 ?

Hi @harsh_gupta4 ,

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.

Best regards,
Daniel

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.

Hi again @harsh_gupta4 ,

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.

Does that make sense for you?
Thanks.

Best regards,
Daniel

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 .

Hi @harsh_gupta4 ,

sure, I fully agree with you.

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.

Regarding your initial request I think there is already an Idea on the Ideas Portal:
Solve the security risk of circumventing | SailPoint Ideas Portal

You may want to add your vote :slight_smile:

Best regards,
Daniel

1 Like

Hi @daniel_neubert , Thanks for sharing the link . I have voted it :slight_smile:
Let me think about this . Thanks for the reply .