Solution
Capture Last Disabled Date & Last Status Change Date:
To identify the user's suspension we are using the following sample properties of the user
CUSTOMPROPERTY13 - Last Disabled Date
CUSTOMPROPERTY62 - Last Status Change Date
When an Active user becomes inactive, the Status Key of the user changes,
- Saviynt will create an Update User Task,
- This Update User Task will update the CUSTOMPROPERTY13 (Last Disabled Date) and CUSTOMPROPERTY62 (Last Status Change Date) with the task creation date (nothing but the current date). This will record the Last Disabled Date for the User, This will be used for calculating the 45 Days
- This Update User Task will also identify all the Active accounts the user has across all the endpoints and flag the CUSTOMPROPERTY23 of the account to TRUE. This is to identify all the active accounts during Suspension and flag them. So that, if we need to activate the accounts on restore, we will activate only the Flagged accounts.
- Saviynt will create Disable Account tasks for all the active accounts by default. If the Identity already has some inactive accounts, Saviynt will not trigger the Disable Account tasks for those Accounts again.
To Perform this, we have created a User Update Rule like below:
The Logic for the Update user Task Goes Like Below.
{ "UpdateUserQry": [ "update users set customproperty13 = '${StatementDate=task.taskdate;StatementDate.format('yyyy-MM-dd')}' where userkey = ${user.id} and statuskey=0", <Update Last Disabled Date only on User Inactivation> "update users set customproperty62 = '${StatementDate=task.taskdate;StatementDate.format('yyyy-MM-dd')}' where userkey = ${user.id}", <Update Last Status Change Date on all status updates> "update users u,accounts a, user_accounts ua, endpoints ep set a.customproperty23='TRUE' where u.userkey=ua.userkey and a.accountkey=ua.accountkey and a.endpointkey=ep.ENDPOINTKEY and u.statuskey=0 and a.status in ('1','active','Manually Provisioned') and (a.customproperty23 is null or a.customproperty23 != 'TRUE' or a.customproperty23!='') and ep.status=1 and u.userkey = ${user.id}", <Flag account CP23 for Suspension> "update users u,accounts a, user_accounts ua, endpoints ep set a.customproperty23='FALSE' where u.userkey=ua.userkey and a.accountkey=ua.accountkey and a.endpointkey=ep.ENDPOINTKEY and (u.customproperty12 is null or u.customproperty12 != 'TRUE' or u.customproperty12 ='') and u.statuskey=1 and a.status not in ('SUSPENDED FROM IMPORT SERVICE') and a.customproperty23 = 'TRUE' and ep.status=1 and u.userkey = ${user.id}" <Unflag account CP23 after Restore Task Creation> ] } |
Restoration:
When an Inactive user becomes Active and the Difference between the Last Disabled Date and Current Date is less than 45 Days, the Status Key of the user changes,
- Saviynt will create an Update User Task,
- This Update User Task will update the CUSTOMPROPERTY62 (Last Status Change Date) with the task creation date (nothing but the current date).
- This Update User Task will also identify all the Inactive accounts which have the CUSTOMPROPERTY23 set to TRUE and unflag them. This is to identify all the inactive accounts which have been Suspended by Saviynt and unflagging them.
- The CP 23 will be unflagged immediately by creating the Update User Task on Enablement along with the restore task creation. When the Update User Task goes into execution, the flags
- Saviynt will create Enable Account tasks for all the account across endpoints for whom the CUSTOMPROPERTY23 is TRUE.
- Enable account task creation takes care of all the enablement of all the flagged accounts based on the condition. Update user task will be created also in the same time. Once WSRetry is triggered, User update task will unflag the accounts and set CP23 to FALSE(4th query in the above box) and restoration tasks will reenable all the accounts.
To Perform this, we have created a User Update Rule like below:
To Create Enable Account Tasks only for the flagged accounts, The Logic Goes like below:
Provide the Following in the Account Filter Query while creating Enable Account Tasks in the highlighted portion in the rules.
| and accounts.customproperty23='TRUE' and accounts.status!='SUSPENDED FROM IMPORT SERVICE |
When an Inactive user becomes Active and the Difference between the Last Disabled Date and the Current Date is greater than 45 Days, the Status Key of the user changes,
- Saviynt will create an Update User Task,
- This Update User Task will update the CUSTOMPROPERTY62 (Last Status Change Date) with the task creation date (nothing but the current date).
- This Update User Task will also identify all the Inactive accounts which have the CUSTOMPROPERTY23 set to TRUE and unflag them. This is to identify all the inactive accounts which have been Suspended by Saviynt and unflagging them.
Saviynt Will not create any Enable account tasks for them, because, After 45 Days, we don't want to reinstate any account of any Endpoint to this User. However, there are a few endpoints that don't operate with this 45 days rule, for them, we create Enable Account tasks immediately on activation, even after 45 days.
Not all the accounts are deleted. Several endpoints have been exempted from this rule. So to those endpoints alone, we have created another rule, to restore the accounts even after 45 days. the snapshot of the rule is available below. This will be used to segregate.
Note: Saviynt will Delete all the accesses and De-Provision accounts in the 45 days and the Action is irreversible. So after Day 45, even if we want to reinstate, we won't be able to do that.
To Perform this, we have created a User Update Rule like the below:
Outcome / Result:
This is one such approach to perform Suspension and Restore.
We have managed to keep the process as simple as possible so that there are lesser components involved in Suspension.
Drawback - Timing issue:
If the User inactivates and gets activated before the disable account task gets processed, The Enable account tasks will not be created. And also the Disable Account tasks will execute after the Identity is enabled. So an Active User will have inactive accounts.
Option 1: We may need to place an analytic to handle this scenario.
Identify all the active users having inactive accounts and create enable account tasks and activate them.
(Or)
Option 2: Provide the Enable account task creation to a Persona for the customer.
Let them manually create the task if there are any failures of Enable Account Task Creation.
References
