Remove Old Access when New Access is Requested/Provisioned

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hey everyone!

I have a use case for our Salesforce connector I could use some advice on how to best try and figure out a solution. We are using the standard OOTB Salesforce connector.

In Salesforce, we primarily use two types of entitlements, Profiles (called groups in IDN) and PermissionSets (called permissionSets in IDN). A user account must have one Profile and can only have one Profile. A user account can have none or many PermissionSets.

We defined several Access Profiles (APs) that are available in our IDN Request Center for users to request access to our Salesforce Dev system so they can test different functionalities. This means that they require switching their access frequently for their testing. Each Access Profile is made up of one Profile and one or many PermissionSets (all Entitlements in IDN). Requesting the access and provisioning works fine. When a user requests a new AP, their Profile is updated in Salesforce with the new one and the PermissionSets are added to the account. Our issue is that that in this model, the PermissionSets a user previously had are maintained on the account so they have their pervious PermissionSets and the new PermissionSets.

What we would like to see is that when a user requests a new AP, their old PermissionSets are removed from the account and the new access is granted. Please note that we are not looking for all entitlements to be removed from the account because if we try to remove a Profile from a user, Salesforce throws an error because a user must have one Profile.

Any thoughts on how we could implement a solution for this? When a user requests a new AP, all of a certain type of entitlement (permissionSets) are removed from the user’s account and the new entitlements are added.

I am thinking of maybe using the Access Request Decision trigger in a workflow if this occurs before the provisioning occurs. Something like:
Access Request approved → all PermissionSets removed from account → Provisioning for the access requests continues granting the new access.

I am just not sure if this flow is what will happen or how to scope the Access Request Decision to those APs or how to configure the Manage Access action to remove all of a specific type of entitlement.

Any thoughts on how to scope this workflow or how to implement a different solution would be much appreciated!

1 Like
2

my two cents, If you are able to obtain the list of previous permission sets, you can utilize the before provisioning rule to include a remove request for the previous permission set, effectively addressing this use case. Alternatively, using a workflow is also an option to achieve the same outcome. However, it appears that there is no available template specifically designed for creating a workflow for this particular use case.

3

Piggy-backing off of Sunny’s response: the beforeProvisioning rule can handle this smoothly. There is a trigger for Entitlement updates (if one is being added) and the action of remove entitlement (by type) would complete your need. The documentation states that the removal will only remove what is presently in IDN, so would remove existing permission sets as part of the plan created by the request for more. This should be close:

    "cloudServicesIDNSetup": {
        "eventConfigurations": [
            {
                "eventActions": [
                    {
                        "Action": "RemoveEntitlements",
                        "Attribute": "permissionSets",
                        "Value": null
                    }
                ],
                "Entitlement Update Triggers":[
                     {
                     "Attribute":"permissionSets",
                     "Operation":"Add",
                     "Value":"*"
                     }
                ]
                "Operation": "Modify"
            }
        ]
    }
2 Likes
4

Sorry for the delay in responding, I got pulled into some other things and this had to be postponed.

I was finally able to revisit this and this solution with the Before Provisioning Rule worked perfectly!

Thank you both very much @sunnyajmera and @cassidiopia for your quick and detailed responses to this topic!

5

Hello @zachm117
We have same requirement. Could you please help us with code snippet of “before provisioning rule”. That would help us expedite our development and testing.

Thank you,
Rahul

6

Hi @rahulbarole ,

This is the beforeProvisioning Rule that worked for our usecase. Anytime a specific permissionSet is being added to a user, we want the old permissionSets to be removed. We created the TEMP_VCS_ONLY permissionSet for this purpose. In our Salesforce Dev environment, our developers simulate different types of users with different combinations of access (bundled together as Access Profiles). So for each of these Access Profiles we use for simulation different users, they contain the TEMP_VCS_ONLY permissionSet so that our developers can switch to different access simulations as needed without just accumulating more access.

                {
                    "eventActions": [
                        {
                            "Action": "RemoveEntitlements",
                            "Attribute": "PermissionSet",
                            "Value": null
                        }
                    ],
                    "Entitlement Update Triggers": [
                        {
                            "Attribute": "PermissionSet",
                            "Value": "TEMP_VCS_ONLY",
                            "Operation": "Add"
                        }
                    ],
                    "Operation": "Modify"
                }

Hope this helps!

  • Zach
1 Like
7

Thank you @zachm117 for this help, appreciate it.

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.