Delegated User Provisioning Best Practices

Posted by Edward Killeen on Wed, Nov 27, 2013

Sometimes there is no authoritative source.  Sometimes you just have to say, "Bob, provision me a user."  These are the cases where you will need a very flexible user interface to control user provisioning workflows.

delegated provisioningSee, that's the cool part, the UI is just what initiates the workflows in EmpowerID, the exact same workflows that are used when it detects a new employee in the HR system.  The same series of events are kicked off: assignment of roles, membership in groups, new accounts in the cloud, notification to the party planning committee, a single sign on dashboard.  It's all there, you are just starting it differently.

Of course, authoritative sources are called that because they have authority.  You can trust them.  With delegated user provisioning, you need to have some additional controls.  The simplest and most efficient is to have an approval workflow shape where somebody in authority has to approve the new user.  Or approve any role with a security level over XYZ.  These approvals can be serial or parallel, they can go to someone in IT or HR or anywhere in between.  They can be decided based on who the new user is.  The important part is that one rogue employee won't be creating any domain admins named Joe Derp.

Another consideration is the complexity of the user interface.  EmpowerID ships with over 400 usable out of the box identity management workflow templates.  About ten of these include user provisioning forms, ranging from what we call "super simple user provisioning" to "user provisioning". 

The difference is what fields are required.  In super simple, the user puts in the name, department, title, and location of the user and EmpowerID dynamically assigns roles.  In simple, there is a dropdown of available roles depending on the attributes already defined and who the requester is (help desk can create X roles and HR can create Y roles for example).  There is also an IT based form where a sys admin who understands things like OU structures and the such can granularly define any attribute.

Just my own personal opinion is that delegated user provisioning should always have an initial lifecycle.  This is easily accomplished by adding an expiration date dropdown on the form or creating a business rule in the workflow that it needs to be certified and renewed within that date period to continue its existence.  This is basically adding attestation to any user provisioning that happens outside of automated processes.

The reason I believe this attestation and lifecycle are important is the use cases for delegated user provisioning.  The most obvious ones are:

  • temporary employees or contractors
  • task based highly privileged accounts
  • additional accounts for an existing user
  • partners and suppliers accounts

None of these types of accounts should be subject to having perpetual access and permissions within your network.  With a strong IAM platform like EmpowerID, these security concerns can be alleviated even on users provisioned outside of normal channels.

Take a look at this video demonstrating EmpowerID's role-based user provisioning; you can see some examples of the delegated user provisioning forms (because showing automated user provisioning makes for a boring demo :) ).  Then schedule a personalized demonstration where we can help you start designing your own user provisioning processes.

Schedule a demo of Delegated User Provisioning

Tags: User provisioning, Identity and Access Management (IAM)