Tracking and scoping identities based on the stage of an identities lifecycle
A methodology I have used in the past to assist in tracking account's and the stage of the lifecycle they are in, is to set a custom staging attribute that changes as the identity evolves through the cycle.
As you read below I am looking for any feedback or other methodologies being used.
I would also be interested to know if it would be favorable to have generic staging and business logic drivers for customers to evaluate and use as starters.
When an account is onboarded, they may not initially have all of the information they need. They will eventually need to have a start date, a manager, birthright roles, cost code, job code, etc to advance on to a different stage.
One possible suggestion is to stage users where they are in the process. All authoritative systems controlling the creation of identities may be bringing in data in various ways and with the various types of accounts, it can become tricky to see where your risks and issues may lie.
I will have two null drivers. One to help trigger users through the life cycle and another for the business logic.
If let's say their "iamStaging" attribute is at a 1, we know that they are a new hire. When they are at a 1, your policies for adding roles, entitlements, login being enabled, etc would be prevented. At a value of 2, you may allow the onboarding of users with roles, entitlements, etc, once they have a manager, they have claimed their account, they have a job code and cost center, etc or whatever pieces they need for the employee type/ identity type. Then they can move to level 3 and level 4 may be for an leave of absence and 5 for termination and 6 for cleanup after a given period of being terminated, etc. And last may be a value of 7 for a rehire, which may change to a 2 rather than a 1, etc.
With tracking the life cycle of the users, you have more gradual insight as to the number of users in a given stage and can see their expected values in that stage and why they didn't progress. You have another analytic you can key off of to do risk assessments. Why does an identity with a stage 6 value still have roles, etc?
In policy you can veto or condition an operation for adding and removing roles if they are in a stage 1. You are helping to insure an order of operations with a uniformity. You may choose to only expose users to your address book if they are a stage 3 and 4 based on their employee type. You have your policies organized in a given area for a given stage for the identity.
If you have insight into IGA 6 and how this may or may not affect this methodology, I would be interested in that insight as well.
Re: Tracking and scoping identities based on the stage of an identities lifecycle
Sharing some thoughts on how I have handled, or seen handled, similar life-cycle account management.
I have used similar "life-cycle" states for managing accounts. I have generally have used a custom string attribute so that the state value is human readable. The common states I have used are combinations along the lines of:
- Pending - a change is pending, job role, location assignment, new hire missing information, etc.
- Active - normal active account
- Leaving - scheduled to depart the organization on a future date
- Inactive - no longer active and account is disabled
- Archived - account moved to an archive context for short term retention
- Terminate - account terminated - could be same as Inactive or in place of Inactive state
- OnHold - legal hold that requires no changes, though the account remains inactive
- Reactivate - short term state for rehire, more a flag for the system to process and activate once more
- Remove - short term state to allow connected systems to delete before removed from Vault
I have generally used a Loopback driver as a base to develop and manage the changing states based on the desired business logic. Currently this could be replaced with a Null driver base as none of the work actually is looping back through the publisher channel. I include a second custom attribute that contains a date that the current state was set to (Active, Inactive, Archived, OnHold, Reactivate or Remove) or the date the State is to occur (Leaving, Terminate, Remove). There may also be additional dates in other custom attributes if certain states require a historic reference (Leaving, Terminate). The driver checks for action to occur on the target dates and processes accordingly. I use GCV values to allow customers to revise business policy in the future. This allows configuration on how many days an account stays in a given state before moving to the next state. For example: remain Inactive for 'x' days before being changed to Archived state. Separate policies handle events generated by Job Trigger, checking for Pending, Leaving, Terminate dates reached to process to the next State, while others handle real time events for State changes to be processed immediately, Terminate, Reactivate, etc. The states and life-cycle times will depend on the business logic required by the customer. That will drive the choice between trigger vs real-time event handling. The separate Policies can also use the configured delay GCV values to determine if it is time to process the state change for the current state.
I have all of the 'State' logic in a single driver and place any Move logic in a second driver. The Move logic can handle changes from just Inactive/Archived vs Active in a flat structure or location/assignment changes in a hierarchical structure. Most IDV's (Vaults) are flat so very limited in the moves required. Connected systems, such as Active Directory and eDirectory Trees may not always be flat so moves need to be handled in those connecting drivers, or connected eDirectory drivers (if not using the Bi-directional eDirectory driver). So most moves actually happen in the connecting drivers and not in the Vault itself.
If the business logic to be applied to the various states is not complex I may lean towards handling that in the State driver. Things like enabling or disabling the account would generally fall there, though not always. If there is more complex needs for business logic I would look at a separate driver for those situations. This could be the handling of enabling or disabling specific functions, roles, etc. that are dependent on the state and involve other drivers for bits of required information. If there is timing involved following a state change, requiring an update/attribute change from a connected system before another driver enables something for yet another connected system, this would be handled in a dedicated business logic driver. Separating the logic this way results in cleaner management as well as easier troubleshooting.
In two situations, one a long term customer and the second a more recent 'similar' customer, I took what had been developed over years for the first customer and refined it to be a more generic state driver that allowed for more granular management and configuration. This was based on lots of learning and experience with the first customer over the years and how their needs have changed. (Amazing how hind sight can be helpful.) I used that experience to develop a fairly generic State driver and structure that I can reuse elsewhere with minimal customization.
Hopefully this provides the kind of feedback and discussion you are looking for in your initial post.