IAM – Object Management – Part One


This is going to take a while.  I’ve been avoiding this next subject since it is so large.  I’m going to break it into about 5 pieces:

  1. User object provisioning
  2. User object deprovisioning
  3. User object maintenance (moves, renames, disabling, logging/audit)
  4. Access Control
  5. Other objects (resources, groups, lists)

I did a post on password management before.  It is one specific attribute of user and some resource objects.  It an be thought of as a prologue.

The list of steps

There are several steps to completing user provisioning:

  1. Initiate Change
  2. Collect Information
  3. Identity Proofing
  4. Ascertain approvals
  5. Enter/Import the required information
  6. Link the user to other systems/processes
  7. Activate the user/Publish the user
  8. Verify functionality
  9. Cleanup tasks
  10. Log actions/Close change

We will look at each step in some detail.  But we need some base knowledge first.


First remember that provisioning a user in a Identity and Access Management system might not be the only system that needs updating.  If your IAM system supports specific applications those might also need to have other registration processes triggered.  If the IAM provisioning is part of a larger process like new hire commencement, the process should feed from or into that process rather than being isolated.  Before designing a new provisioning process try and find all such linkages.

If user provisioning is linked to other systems and processes, do not design the provisioning process in isolation.  Involve the other systems and processes into the design.

Second, not all user accounts in an IAM are the same.  So your provisioning process might need to be different for different types of accounts.  Some account types include: privilege use accounts (administrators), limited use accounts (test, guest, temporary), service accounts (used by an application not a person),  application specific accounts (separate accounts for specific applications) , and normal accounts.  This list is not exhaustive.  Try and determine the types of users in your system before designing your provisioning processes.  Also take into account that new account types might arise during the life of the IAM system.  You must be flexible in dealing with them.

Third, decide who will be doing your user provisioning.  This may be different for different account types and for different steps of the processes.  Will you have a dedicated team and will other operations teams be able to provision users?  What role do you envision for the Service Desk?  If your provisioning ties into other non-IAM processes, how will the administrators/users of those processes interact with your process?  What role will user self service play?  How much of the process do you want automated so that no manual intervention is needed?

Fourth, remember that your goals in user provisioning are to achieve completeness, correctness, standardization and efficiency.   Completeness means that all the required information is in the system at the end of the provisioning process.  Nothing additional will be required.  Determine if there is optional data.  Correctness means that the information is correct.  How will correctness be validated?  Standardization means that when you compare similar data between users it is in the same format.  Take the time to determine your data formats: addresses, phone numbers, names, etc.  Efficiency might mean a trade off on the other three goals.  Do not get hung up on a step.  Determine if all steps are needed. All four goals are necessary to make the user object useful and to reduce costs.  Cost reduction is primarily achieved by minimizing the amount of user maintenance that is later required for the user object.

Five, remember that user provisioning is a process not a technology.  Keep your technology in mind as you design.  There may be specific constraints and required information based on your IAM technology.  But the technology should not drive the process.  n a perfect world, you’ll decide on your IAM technology as part of the design process.  It is rarely a perfect world though.  Your IAM system might be dictated to you or may already exist.  Also decide how much customization of your system will be acceptable to support your process.  Customization will incur costs for support and upgrades.    No technology will map exactly onto your process.  So you must have some method of bridging the gaps.

Initiate Change

What starts the user provisioning user process?  Likely it should be one of these five methods:

  1. User self-registration
  2. Service Desk Ticket (they get it from a call, e-mail or other system)
  3. Event in another system – if your IAM is linked to other systems, you might get notified that a new user is required
  4. Linkage to another process – for instance the commencement process might result in a notification
  5. Direct Operational team request

Regardless of how the change is initiated, you will want to ensure that the request is logged.  If you have a service request ticket system, that is an appropriate place.  If not, create a log somewhere – perhaps within the IAM system or on the user object itself.  The log should indicate how the request came in, who requested it, when and why.

Decide which methods of initiation are valid.  Decide which are not.

Collect Information

See the IAM post on Privacy.  Collect the information required and only the information required.

If the information does not meat your standardized formats, you will need to normalize the data.

Decide what you will do if the information is incomplete?  reject the request?  Track down the information?  Proceed if the mandatory information is present.  If some data will be left incomplete what will be your process for obtaining it later.  For instance with a new hire, their phone may not yet be provisioned when they first need their account or their e-mail address might depend on the provisioning process completing first.

Identity Proofing

Determine that the user registering is the person they say they are.  See my earlier IAM posts for details.

Ascertain approvals

Determine what approvals are needed, who will provide them and at what steps in the process they are required.

Here are some people from whom approvals might be necessary:

  • management/ supervisors (especially for new hires)
  • security (especially for privileged accounts)
  • application owners (for application specific accounts)
  • HR (for new hires)
  • Payroll/Budget/Expenditure Officer (if there is a cost to the provisioning)
  • Change Manager (per the change process)

What can be done, if anything, with incomplete approvals?  How will you ensure that aprovals are timely?

What information must be sent to the approver?  Keep your privacy concerns in mind.

Make sure all the approvals are logged.

Enter/Import the required information

An obvious step.  Using the steps of your IAM system, create the user object and enter all the required information.

Activate the user/Publish the User

Publish the user means to make it visible in your directory.  Remember a directory is generally not private – other users will see the information published.  Determine if any of the data needs to be hidden.  If the IAM directory cannot ensure the privacy of all the data, some data might need to go into a different system.

Activate the user means to set the initial credentials and make them available to the person who will use the account.  You may require that the credentials are modified the first time they are used.  You may required that the credentials time out of they are not used within a certain time period after they are provided and that the activation process will need to start again..

After activation the user object should be available for use.  Note – I’ve set access management as a separate process so the user object may not have authorization to do anything yet.

Link the user to other systems/processes

If your provisioning process is linked to other processes (commencement, access management, application setup, etc.)  you must notify those processes.  Provide them the information they will need to proceed.

If your IAM system is linked to others, determine how they will be notified of new users.  Is it an on demand notify?  Or is it a timer (daily, hourly, weekly, etc.).  Perhaps you will provided delta changes to the other system or maybe a full dump of all users on a regular basis.

Verify functionality

Determine that the person can actually use their user object to access your system. Verify the completeness and correctness of the data with the user.

If this step is skipped, determine how you will receive notification if the account does not work or has incorrect details.

Cleanup tasks

Other items can be done here.  Does anyone else need to know of the newly provisioned account?  Were any steps skipped wholly or partially?  Should they be completed now?  Do any other systems need updating (billing, time management, etc.)

In designing your process make a note of any feedback you get from other teams and stakeholders.  They might drive out additional cleanup tasks.

Log actions/Close change

Every step should be logged with who did it (and why if it isn’t obvious).  Finally, you can close the change.


One thought on “IAM – Object Management – Part One

  1. […] June 23, 2010 at 12:49 pm (Technology) So Part 1 (which included a quick overview of what is to come) can be found here […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s