Default Fallback Role

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hi Experts,

We have an use case for one of the webservices connector.

The user would request some access through request center or might get the access through Role but there are chances that some of the user might request for another higher level access for certain number of days.
Access - Single value attribute

Now, Whenever the temporary access is revoked after certain number of days then the user needs to get back his original access.

Please suggest that how this can be implemented.

1 Like
2

Do you have a defined default role? Like everyone gets Read-Only other than the elevated role you mentioned?

If that is the case, create a beforeOperation rule for your “Remove Entitlement” HTTP operation. Have the rule check to see what role is being removed, if it is the elevated role, modify the payload to have it switch the role to the default role rather than removing the entitlement.

3

Access attribute is a single-value attribute, when the user requests a higher privilege temporarily, the original value needs to be preserved to restored it later.

Capture the current value –store the user’s existing access value in an identity or account attribute.

Provision temporary access with expiration date -update the web service account with the new access value when the user requests and set an expiration date

Restore original access after expiration -When the access expires, the entitlement is removed automatically, a workflow or rule can trigger another provisioning event, the stored original access value is sent back to the target system through the Web Services connector

This requires a Workflow or provisioning rule to restore the original attribute value because the connector only removes the temporary access and does not automatically revert to the previous value.

4

Questions:

  1. When the user is granted a higher level access, how does the current access get revoked? Is it an automatic process from the end system? Or do you have some logic implemented in ISC?
  2. How would the old access have been provided? BR Role or Access Request? Or both?

Depending on your answers to above, a solution can be designed

5

Thank you Experts for the suggestions,

The target system do not have specific API to add or remove role.
It is a put request like below, So I created a put request to add/remove the role

{

// “firstName”: “Prince”,

// “lastName”: “Doe”

“roleGroup”: “abcdefg82ee8”, // Either roles should explicitly provided or a roleGroup

“usermetadata”: [  {

        "metadataId": 23456,

        "value": "test211"

    }

]}

/>

6

Thank you for your reply,
THere is no one single default role, The default role depends on the certain departments.
FOr now it is 3 kinds of default roles which needs to be checked when assigning.

7

Thank you for your reply, Curretnly using the Workflow is our of scope as they are limited.
I am checking the Rule option.

8

Thank you for your reply,
1 - IT is a simple put method and the attribute is single value attribute so it can accommodate 1 value at a time.
2 - The access gets granted through both BR or Access requests

9

Hi @Abhim1 ,

  1. Whenever a user requests ad-hoc access, first capture the user’s existing access and store it in a lookup transform, where the nativeIdentity acts as the key and the current access (group/entitlement) is stored as the value. A single lookup transform is created, and during every ad-hoc access request, the transform is updated through a Before Operation Rule to add the user’s existing access entry.

    {
    “type”: “lookup”,
    “name”: “Access Name”,
    “attributes”: {
    “table”: {
    “nativeIdentityforuser1”: “groupname”,
    “nativeIdentityforuser2”: “groupname”,
    “nativeIdentityforuser3”: “groupname”,
    “nativeIdentityforuser4”: “groupname”,
    “default”: “defaultValue”
    }
    }
    }

  2. After storing the existing access in the lookup transform, proceed with provisioning the requested access for the user.

  3. When a Remove Entitlement event occurs, first check whether the group attribute is empty.

  4. If the group attribute is empty, retrieve the value from the lookup transform using the nativeIdentity as the key, where the stored value represents the user’s previously existing group or access, and use it accordingly.

1 Like
10

Based on what I understand, existing role will be removed while granting a new role. If old role was granted via BR or Request, ISC will try to provision the same again when it sees user has lost it. This might result in an unexpected behavior where newly added role is replaced by old role during next refresh. Have you checked if this is happening?

11

Agreed, I have added another criteria to check if the entitlement attribute value is null

12

Thanks, This looks like a solution.
Let me try and update here.

13

Hi,
If possible could you please help me with the code snippet to call the transform and update it.

14

This is going to be problematic, race condition of the update.