Access Request for Account Management

Identity Security Cloud (ISC) ISC Community Knowledge Base
, ,
1

Dear Community,

Introduction
This is about adding a Feature to make enablement/disablement of accounts requestable in IdentitySecurityCloud after the necessary approvals.

Background

Firstly, let us understand the need of such feature to have users to request disablement/enablement of accounts for other users when they are automatically managed by Lifecycle state process.

Is it risky?

Well, I don’t think so when we safeguard these requests with right approvals and right segmentation controls in place.

Is it necessary?

Here are few reasons what I think can be legit for such a feature:

  1. Emergency Termination

We can have an Emergency lifecycle state, which could disable all the accounts of the Identity. But, if application admin team needs to disable only particular source account of the user, the current option is to have a ticket raised to respective IAM Operations team who can manually disable the account on Identity.

It may cause delays in servicing the ticket/request from the operations. Providing an approach to request for disablement/enablement of account to a source admin team speeds up the process.

  1. License Management

Application teams often need to keep an eye on licenses of the accounts and balance them accordingly. Team could use a feature to manually place disablement of account which can save licenses based on the usage

  1. Inactivity Management

Last logged Date is a key information which is not mandatorily available for all the connectors. When there is a need for admin team of application to inactivate the accounts based on the information at the target system, requesting them in IdentitySecurityCloud can be a good option.

These are some cases that I could think of as a start, there could be many other. We do not have an out-of-the-box way in ISC to make this happen by any request process.

Solution Design
I utilized the Role and Workflow feature to achieve what is needed.

Workflow Design:

image
image655×884 42.5 KB

  1. Roles

Defined Two Roles(I call them as Source Activity Roles) for the source for enabling and disabling the account respectively as below. We can either define segmentation to have these roles requested by an application admin/owner team. Or can be safeguarded by approvals. Please note that the level of approvals can vary and can be defined based on the requirements for each source role.

-Disable Account
-Enable Account

Note:
Strict naming convention is followed for this requirement to achieve the needed scenario and make it as generic as possible.

  1. Workflow
    Developed workflow to handle the access requests with below high level module requirements:

Trigger(Access Request Decision):

  • To detect the access requests requested for the defined Source Activity Roles
  • To verify if the request is completed and approved

Action:

  • Identify the Source and action type(disable/enable) requested. Defined variables to capture the source name and action type based on the role requested
  • Get the current accounts of the user and perform a loop operation on the identified source accounts
  • Perform the respective action(disable/enable) on the account based on the role requested
  • Revoke the source activity role for the user as it is needed to be cleared to have it requested again for another day

Thank you!
Uday Kilambi

4 Likes
2

Hello @uday_kilambiCTS
Few Questions:

  1. So when you say 2 Roles for enable/disable, you mean to say for each source on the tenant ? If yes then Question 2 as below, if No then question 3
  2. If Yes - Then what will be the content of that ROLE ?
  3. If No - Then wont you need a dummy entitlement for each source to be present in each ROLE ?

Rest all looks good to satisfy the use case and should be a easy to go option for making a disable request.

3

Hello @harshamin9

Yes, we need two different roles for each source with respect to each action i.e., disable and enable actions. These roles are empty, we do not need to add any actual entitlement/access profile.

That was our initial challenge on not going for an access profile. Not every source contains an entitlement equivalent to request as an access profile. For eg: valid_until could be an attribute which defines the status of the account, which we cannot define/promote as an entitlement.

That is where Role helps us, for a role it is not mandatory to have an entitlement/access profile. It is a plain no-access role with a strict naming convention. All the magic of account action happens inside the workflow. Hope it is clear.

Regards,
Uday Kilambi

4

Hi Uday,

Great article. Is it possible if you can attach the workflow as part of the post.

5

Thank you @kavindar_sharma.
Yes, I am planning to do submit a CoLab with the actual workflow and update this page with the link about it. Only information that needs an update is the owner details, rest all works seamlessly and the workflow will be good for use.

Regards,
Uday Kilambi

6

Hi @kavindar_sharma ,

Here is the CoLab post with the workflow details as well.

Regards,
Uday Kilambi