Remember your first day on the job at your company, you were given access to a few things, keys to the kingdom if you will.  A year later you were promoted, given new responsibilities and a few more of these "keys".  By the time you've been at a company for a few years, your "keychain" looks like one of those giant keyrings that a NY super has.

This illustrates why everything in Identity Management needs to have a lifecycle, a beginning and an end.  Obviously, a user has a lifecycle: hire date and fire date.  Their roles need a lifecycle based on what gives them that role (department, title, location).  Similarly, group memberships and existence need a lifecycle. 

Access to a resource needs a lifecycle.  Not just membership in the group or the group's existence, but the access of that role or group to a resource (file share, application, et cetera).  When you provision a user in an application like Google Apps, you want to periodically ensure that the user should still have that account.

Everything needs a lifecycle.

So, how do you manage that?  There are two primary methods, attestation and dynamic assignment.  And, just to invoke Inception, sometimes you may need to attest to the rules of dynamic assignment!

Let's start with attestation.  This is not only a good business practice, but required for all sorts of regulatory and compliance reasons.  The owner of an object or resource needs to periodically attest or certify that that resource should still exist; this could simply be responding to an email that yes, this resource should still exist and that the access levels are correct.

In addition to certifying that the object/resouce should still exist, all access needs to have a 360 degree view of its permissions.

User:  The manager of a user or an HR contact should periodically attest that the user still exists.  And attest that the user has the correct group/role memberships and correct application/resource

Role / Group:  This role and/or group has the correct membership.  This role and/or group has access to the correct resources.

Access to Resource:  This resource has the correct roles and/or groups granted access.

Attestation should allow for email responses, have a complete dashboard with that 360 degree view from the perspective of the user/member, role/group, and resource and give a flexible timeline for attestation based on the security level of the access.

A lot of this can be managed dynamically to reduce the number of attestations needed.  If you know that every manager in HR should have access to the 401K administration SharePoint site, just create a dynamic role that queries SAP HCM (or whatever HRIS you use) and places those users in the correct role or group.  You don't need to attest to the membership of the role or group, your user attestation will certify that the titles are correct and you are then guaranteed that the membership is correct.

With a metadirectory like EmpowerID, these attributes can be synchronized through any number of sources and updated every 5 minutes.  They dynamic memberships will be accurate and security will increase.

The same principle can then be applied to application access.  If you are managing roled dynamically, your provisioning and deprovisioning workflows can check role memberships and create/update/delete application accounts based on role based provisioning.  That HR Manager above moves over to Marketing?  Their role changes, the EmpowerID workflow will deprovision their account in SAP HCM and provision a HubSpot account for them!  Dynamically and automatically.

The key to all of this working is a cohesive Identity Management platform that allows you to map business process to identity processes.  Your metadirectory and RBAC engine and workflow platform all work together with a slick HTML5 user interface to give you all of the capabilities to make sure that the right users have the right access to the right resources.