AnsweredAssumed Answered

lock account on attribute change

Question asked by Markus Calmius on Dec 8, 2020
Latest reply on Dec 10, 2020 by Markus Calmius

Like • Show 0 Likes0
Comment • 3

Hello,

we have a target system (oracle db) that isn't completely integrated yet. All we have is account governance. That is a Dashboard showing orphans, dormant and terminated accounts (based on the risk analytics dashboard: RSA IGL Recipes: Risk Analytics Dashboard )

Now they would like to include an automatic process of locking the account when a specific identity attribute changes. Any ideas on how to do this the best way?

Right now I'm toying with the idea of using attribute-sync for the specific attribute and create a specific workflow, but it feels a bit cumbersome.

So, any pointers will be greatly appreciated.

We're currently running 7.1.1 P04 (but will upgrade soon(ish))

Markus Calmius Dec 10, 2020 7:03 AM

Correct Answer

I ended up doing what I initially thought of. Since the organisation-attribute isn't used in this specific application I set up an attribute sync for that attribute.

The workflow is extremely simple: Start -> Get Username -> Send Disable Account -> Mark Verified -> Stop

So, yeah, there are room for enhancements, specifically error handling etc. but it will do the trick for now.

See the reply in context

No one else had this question

Outcomes

Clive Morrish

Dec 8, 2020 4:59 AM

Hi Markus,

The way I'd approach this would be to use a 'dummy' application and local entitlement. From a very high level, the process would look something like this:

1. Attribute changes on User

2. Attribute change rule detects change and grants local entitlement in dummy application using the 'Create Change Request - Add Entitlements' action

3. Fulfillment workflow on the dummy application contains logic/node to Lock account

Something to be aware with this approach is that the change request generated from the rule will be to add the local entitlement, which is always going to complete. If you want to report on the success/failure of the Lock Account, this will need to be via Admin Errors. The following post provides additional details on that: RSA IGL Services 101: Explaining Workflow Nodes - "Create Admin Error"

Hope that helps.

Thanks,

Clive

1 person found this helpful

Actions

Markus Calmius @ Clive Morrish on Dec 8, 2020 8:20 AM

Thanks,

I'll look into this as well.

/Markus

Actions

Markus Calmius Dec 10, 2020 7:03 AM

I ended up doing what I initially thought of. Since the organisation-attribute isn't used in this specific application I set up an attribute sync for that attribute.

The workflow is extremely simple: Start -> Get Username -> Send Disable Account -> Mark Verified -> Stop

So, yeah, there are room for enhancements, specifically error handling etc. but it will do the trick for now.

1 person found this helpful

Actions

3 Replies

Clive Morrish Dec 8, 2020 4:59 AM
Mark Correct
Correct Answer
Hi Markus,

The way I'd approach this would be to use a 'dummy' application and local entitlement. From a very high level, the process would look something like this:

1. Attribute changes on User
2. Attribute change rule detects change and grants local entitlement in dummy application using the 'Create Change Request - Add Entitlements' action
3. Fulfillment workflow on the dummy application contains logic/node to Lock account

Something to be aware with this approach is that the change request generated from the rule will be to add the local entitlement, which is always going to complete. If you want to report on the success/failure of the Lock Account, this will need to be via Admin Errors. The following post provides additional details on that: RSA IGL Services 101: Explaining Workflow Nodes - "Create Admin Error"

Hope that helps.

Thanks,
Clive
1 person found this helpful
Like • Show 0 Likes0
Actions
- Markus Calmius @ Clive Morrish on Dec 8, 2020 8:20 AM
  Mark Correct
  Correct Answer
  Thanks,
  I'll look into this as well.
  
  /Markus
  Like • Show 0 Likes0
  Actions
Markus Calmius Dec 10, 2020 7:03 AM
Unmark Correct
Correct Answer
I ended up doing what I initially thought of. Since the organisation-attribute isn't used in this specific application I set up an attribute sync for that attribute.
The workflow is extremely simple: Start -> Get Username -> Send Disable Account -> Mark Verified -> Stop
So, yeah, there are room for enhancements, specifically error handling etc. but it will do the trick for now.
1 person found this helpful
Like • Show 1 Like1
Actions

lock account on attribute change

Outcomes

Related Content

Recommended Content