Background: Currently, we aggregate accounts from HR (authoritative source) and create identity cubes, but we only aggregate specific parts of HR data. This is to manage employees that meet certain conditions and exclude those who require minimal direct management, such as service accounts. For example, if the usertype is 1, 2, 3, or 4, they are included in the aggregation and an identity cube is created. However, if the usertype is 5, even though the account exists in the authoritative source, it is not included in the account aggregation and no identity cube is created.
Unfortunately, some of these accounts were previously included in the aggregation and were managed. Depending on the customer’s environment requirements, there may be situations where an identity with usertype 2 changes to 5 or an HR account with usertype 5 changes to 3.
Question: I am curious if there is a way to manage these users in the grey zone through actions like querying, enabling, disabling, and managing access.
Currently Considered Possible:
Detecting user information changes (usertype) through Native Change Detection.
Checking the Deleted User Log of Identity Cube.
Currently Considered Not Possible:
Managing account entitlements (approve/revoke).
Disabling/Enabling the account.
Does anyone have any ideas on how to address this?
Deleting identity is a possibility for your use-case? If it is then you may simply drop the account from your source and that in turn will remove identity.
Let me know if I am missing anything in the use-case.
This usecase could possibly be handled through a combination of Lifecycle States and Workflows.
One option would be something along the lines of: Workflow 1 - Trigger Identity Atttribute Change (usertype oldValue==5, newValue ==3) - Change LCS to "Activating" through API request.
Workflow 2 - Trigger Identity Attribute Change (LCS oldValue == unmanaged, newValue == Activating) - Change LCS to "managed" through API request.
and similiarly for included in management → excluded from management
The LCSs “managed” and “unmanaged” could then be set up in the UI to handle activations and AP assignments, alternatively you could add a check for LCS in the role assignment criterion.
There might be an easier way to handle this, but this is how I would do it - quite similiar to how I would handle an AD OU move.
Thanks for your comment. In our current design, LCS is managed through a separate attribute called status, and usertype does not affect LCS. However, usertype is included in the account aggregation criteria, which causes issues.
The problematic scenario typically occurs as follows: As mentioned earlier, the usertype can change from 2 to 5 while the LCS is still active. In this case, roles and access profiles assigned by IdentityNow are revoked, and the identity cube is deleted. Specifically, if the some user’s usertype changes from 2 to 5 while the LCS is active, and then the usertype 5 user’s LCS is terminated in the native source, it becomes difficult to audit since it is no longer directly managed.
I understood your suggestion as including usertype in the LCS criteria. Please let me know if my understanding is incorrect.