During an identity management project, we frequently have discussions with our customers about provisioning via workflow. Some customers expect that they will have to deploy workflow to perform any type of provisioning while others hope to fully automate the entire process.
The decision on whether or not to implement workflow can be based on technology requirements or based on political or other environment requirements. Some identity management products are architected around workflow and therefore it becomes a necessary component to your provisioning solution. Some organizations feel the need to maintain control of their solution and want a human to intervene before any access is granted. Any approach taken is fine so long as it meets your requirements.
Typically our customers want to know what we’ve seen and what we recommend based on our experiences. Specific technology capabilities aside, we feel it is best to fully-automate the entire identity lifecycle (provision, change, de-provision) wherever possible and only use workflow to fill the gaps. These gaps come in two parts, lack of data or regulatory compliance requirements. In order to fully automate the entire provisioning process, your authoritative systems (e.g. HRMS) must provide the data necessary to make that happen. Typically we have enough data about users to know how to create them, where to place them and what access to assign them. However, HR doesn’t always track at the granular level required for assigning low level access. This is especially true with regards to provisioning the IT department staff. An IT department is made up of support, development, engineering, security and other personnel types but they are all typically assigned to the “IT Department” in the HRMS. To assign granular permissions, like “Domain Administrators” membership in Active Directory, you need to employ a workflow solution. In some cases, access could be automated but regulatory compliance requires an audit trail of who approved the access and when. Again, in this case we recommend implementing workflow so that “human touch” can approve access and those actions can be stored in an audit repository. Even with human intervention for approvals, the actual provisioning in the systems will hopefully be fully automated.
Identity Automation is also building a solution that takes de-provisioning via workflow to the next level. Typically organizations will provision access and that access will remain for that user until they leave the organization. In some cases where we are fully automating the user lifecycle, we will strip old access and apply new access when users transfer to a new department or location. However, if access was granted via workflow, that access usually doesn’t go away when someone changes their organizational role. Using our workflow solution, application owners can re-attest access to their resources on a scheduled basis. We apply a maximum TTL (time-to-live) to a resource and any access to that resource must be re-attested within that time period. For example, if you are grant access to the Accounts Payable resource, recipients would lose that access if the owner of that resource doesn’t re-attest their access within 6 months. This is another fine example of when workflow is useful, if not mandatory.
Comments