Click HERE to see how Saviynt Intelligence is transforming the industry. |
07/21/2023 02:11 PM
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
07/21/2023 03:30 PM
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. |
Thanks,
Devang Gandhi
If this reply answered your question, please Accept As Solution and give Kudos to help others who may have a similar problem.
07/21/2023 11:50 PM
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
07/22/2023 12:47 AM
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:
07/22/2023 01:55 PM - edited 07/22/2023 01:58 PM
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)
07/22/2023 09:19 PM
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
07/23/2023 09:02 AM
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.
07/23/2023 11:14 AM
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.
07/23/2023 12:13 PM
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)