Use Case
This article explains how request rules in Saviynt can be used and things to keep in mind while implementing request rules.An Illustrative Requirement:
Let us assume there are multiple departments in an organization, each department provides set of application access based on entitlements and users can select the list of application on which they need access.
Certain applications can be accessed by more than one department and certain applications are dedicated to one particular department. The below table illustrates the access mapping.
Application Name | Department 1 | Department 2 | Department 3 | Department 4 |
Application 1 | Yes | Yes | Yes | Yes |
Application 2 | No | Yes | No | No |
Application 3 | No | No | Yes | No |
Application 4 | Yes | No | No | No |
Application 5 | No | No | No | Yes |
Application 6 | Yes | No | Yes | No |
Application 7 | No | Yes | No | No |
Application 8 | Yes | No | No | Yes |
Application 9 | No | No | Yes | No |
Application 10 | Yes | No | No | Yes |
The ARS form should provide option to support above table and if user selects a department, the access/application belong to the selected department only should be visible for user to select. When user selects department and one or more access, the user must receive selected entitlements and additional entitlements belongs to the department.
This addition entitlement need not be visible to user nor user need to select them but automatically provisioned. If user changes the department, the additional access given to user (that are belongs to earlier organization) must be removed and additional access belongs to selected department must be provisioned.
For example,
If user selects Department 2, user must be presented with an option to select entitlements that are marked as ‘Yes’ for Department 2 in the above table. The selected access/entitlements must be provisioned along additional entitlements belongs to Department 2 (Entitlements ‘Dept-201’, ‘Dept-202’, ‘Dept-203’)
If user selects Department 3, user must be presented with an option to select entitlements that are marked as ‘Yes’ for Department 3 in the above table. The selected access/entitlements must be provisioned along additional entitlements belongs to Department 3 (Entitlements ‘Dept-301’, ‘Dept-302’)
If user selected Department 2 in earlier request and now want to change to Department 1, user must be presented with an option to select entitlements that are marked as ‘Yes’ for Department 1 in the above table. The selected access/entitlements must be provisioned along additional entitlements belongs to Department 1 (Entitlements ‘Dept-101’, ‘Dept-102’) and Entitlements ‘Dept-201’, ‘Dept-202’, ‘Dept-203’ must be de-provisioned.
Solution
Filter and display entitlements in ARS can be achieved using ‘Config For Requestable Entitlement In ARS’ in entitlement type configuration.
Provisioning and deprovisioning department specific additional entitlements can be achieved using ‘Request rule’ along with Dynamic attribute at endpoint level.
Limitation: The ‘Request rule’ solution will work only when there is a new account or modify account task is there. If the security system is configured with ‘EntitlementsOnly’ option for ‘Create Task Action’ option, it will not create any new/modify account task and it’ll not trigger request rule.
Create a dynamic attribute ‘Org’ at endpoint level as shown below.
In this example, attribute type is configured as ‘Enum’ and set of values presented for user to select.
These values will represent Department 1, Department 2, Department 3 and Department 4 in the table presented in requirements section of this document.
The selected value for dynamic attribute must be stored in an account custom property attribute for request rule to work. This attribute needs to be configured as ‘Required and Editable’ so the user can select on the access request screen.
Go to ‘Organizations’ under ‘Identity repository’ in Admin module, create 4 Organization objects which represent each department that are mentioned in the table.
Note: Organization object modification requires approvals so configure required workflow for ‘Organization Modification Workflow’ under ‘Configurations – Global Configurations – Common’ in Admin module.
After creating each Organization object, go to Entitlements tab and add the entitlements required. These are the department specific entitlements that will be provisioned when user select it in ARS page and these entitlements will not be visible for user to select.
After adding/modifying entitlements, send for approval. The ‘send for approval’ option is available in version tab of Organization object. The request for approval will be routed based on the workflow configured in ‘Organization Modification Workflow’ option.
Go to ‘Request rule’ under Identity access rule in Admin module.
Create a new request rule, specify rule name, description, specify the condition and action. The rule must be configured as
If endpoint id =XX AND attribute name is ‘Org’ then ‘Add Entitlements from Organization’ ${Org}
The endpoint id is the id of the endpoint where dynamic attribute is configured. The Request rule may support using endpoint name instead of using endpoint id but it’s not tested while writing this document. Also, this document is created for AD based logical endpoint or endpoint-filter based endpoint.
Outcome / Result:
When user request for access in the specified endpoint, the new account and access provisioning task will be created (after approvals as per the workflow configured in the security system).
At this stage task will be created only for the list of entitlements selected/requested in the ARS page and there will be no provisioning task created for department specific entitlements (Entitlements ‘Dept-101’, ‘Dept-102’). Provisioning task for these entitlements will be create when WSRERTY job executed. After WSRETRY job execute, the completed task table will show additional provisioning task for Entitlements ‘Dept-101’, ‘Dept-102’.
Similarly, when user change the department name in ARS form, a modify account task will be created and when WSRETRY job execute, it will generate remove access task for the entitlements assigned part of earlier department and add access tasks for the list of entitlements belongs to new department selected.
References
https://docs.saviyntcloud.com/bundle/EIC-Admin-v23x/page/Content/Chapter05-Policies/Creating-Request...
