Identity Lifecycle

[oana_agheorghiesei]

Hello everybody, I am working in understanding some of the best practices in the identity lifecyle.

I have come to the conclusion that the best way to start is identifying the states of the identity. Many of the requirements for the implementation of Sailpoint IIQ can be derived from this.

Example of a list of the states:

1. Registered:  the user/the system has completed a process that concluded with the creation of an identity; for some users the trigger might be a registration process, for others an event on the HR system; the identity has only birth rights, if configured, otherwise it cannot access the resources of the organisation
2. With authorized access: the user has completed a process (composed of activites such as request for access, approval, provisioning of the access on the target system) that concluded with an access being granted to the user; the user can now access specific; the user can turn to the previous state (registered) in the case his access is not granted or it is revoked for some reasons (like a change of department) by the data owner
3. Inactive: the user hasn't logged in for a long period of time (this might not apply for all organisations), so his status should be modified in such a way that he doesn't have access to the organisation resources (is part of the requirements to explain the login events that should be taken into account, and how long after the last login event should the user become inactive)
4. De-registered: after a predefined period the user can pass from inactive to de-registered, that is his account  can now longer be used to request access to resource (again, specific requirements have to explain for how long a user can be de-registered, how can the user go back to an active state, what happens at the end of this state)

Is there something like best practices for this or has any of you done some thinking about this?