For Remove Birthright Task check if Access is Assigned From Rule

[shibinvpkvr]

hello,

can anyone explain me the use case for below configuration in Saviynt. What is recommended and why?

For Remove Birthright Task check if Access is Assigned From Rule

[dgandhi]

https://docs.saviyntcloud.com/bundle/EIC-Admin-v23x/page/Content/Chapter06-EIC-Configurations/Config...

For Remove Birthright Task check if Access is Assigned From Rule

Use this setting to create access removal tasks only in the event of a birthright failure, but only if the access was provisioned to the user through the birthright rule.

[armaanzahir]

Hi @shibinvpkvr ,

Access to an account of a user can be assigned in many ways within EIC (ARS,Rules,Actionable Analytics) etc. 

If the above setting is checked, then the birthright access will be removed only under the condition that it was assigned from the technical rule (not from ARS/Analytics etc) in case the birthright conditions fail. (Remove birthright access if condition fails is checked)

Configuring Rules (saviyntcloud.com)

Thanks,

Armaan

[pmahalle]

Hi @shibinvpkvr ,

Accesses can be provisioned and removed many ways in Saviynt like through ARS, Rules, Actionable Analytics etc. 

Suppose you added accesses using technical rule as a birthright, and requirement is to remove those through technical rule only and not other way, then you need to enable this setting/configuration.

Once you enabled this settings and checked the Birthright checkbox in technical rule, whenever conditions of technical rule not matches with users, accesses assigned by that technical rule will be removed.  

Note: It only removes the access which were provisioned to the user through the birthright rule.

Refer below document:

https://docs.saviyntcloud.com/bundle/EIC-Admin-v23x/page/Content/Chapter06-EIC-Configurations/Config...

[shibinvpkvr]

As of now I haven’t checked this configuration. Still I have setup lot of birthright rules to assign different enterprise roles/access. Many of those are configured with “Remove Birthright Access if condition fails” as well. As of now I can see that it is all working as expected. It’s get assigned when the condition satisfies and gets removed when it doesn’t satisfy. 

I am trying to understand what difference it makes if I check this configuration. I have gone through the documentation already and couldn’t understand the use case properly. Does that mean if I don’t check this configuration, there is a possibility that access could be removed when birthright fails even though the access was not assigned earlier through the rule? (May be through an access request I got that access/role earlier)

[armaanzahir]

Hi @shibinvpkvr 

Yes, if that role is assigned via ARS, it would be revoked if the birthright condition fails if this setting is not checked. Checking this setting would ensure that the access would be revoked only if it had been provisioned from the rule in the first place. 

Thanks,

Armaan

[shibinvpkvr]

Thank you. So I assume the best practice is to keep this checked in global configuration correct? I have noticed that Saviynt keeps this as unchecked by default.

[rushikeshvartak]

Yes, its by default Turn off because based on business requirements this can be turn on. Best practice to keep turn off if those access needs to be removed as user should not have particular access if conditions are not matching due to change in users metadata.

[shibinvpkvr]

I have tested this and it doesn't remove the role which I assigned from ARS even if the condition failed in the technical rule (global setting is not checked). I did not see any difference in the behavior with or without that config is checked. I am suspecting this config needs to be checked only if there are multiple birthright rules/tech rules assigning the same access with conflicting conditions. Similar to the one below. 

(Remove Birthright access if condition fails settin... - Saviynt Forums - 30557)