IAM -Object Management – Part 3

Other user object management

So, we have nearly gotten to talking about access management (authorization), but first let’s look at some of the other user processes besides provisioning, deprovisioning and password management.

Moves

So we haven’t talked about how a directory works, but it is a hierarchical data structure.  Generally that structure is organized to support your corporate needs – by geographical location, or object function, or business unit, or administrative unit or other need.  A user object will only be at one place in your hierarchy (although links are possible).  This raises the possibility that when something changes the user must be moved.

Technically a move is easy.  But it has all the same potential complications as a deprovisioning.  Who approves it?  What happens to the data?  What links to other systems does the move impact?  It might be enough like a deprovisioning that your process might actually be to deprovision the user and have them provisioned again.  But, then you lose the continuity of the object.  If auditing the activities of the user for their whole stay in the directory is a requirement then either the object needs to stay consistent or a link needs to be made between the old and new objects.

Rename

The worst possible change.  If there is any business logic attached to the name then this can be difficult.  An easy directory architecture is to have all the name fields in a directory reflect one another.  The given and surname, the e-mail address, the directory common name, display names, the credential name or certificates might be issued by the name.  If you did not use MBUNs to link your IAM system with other systems then the name might also be a key field used for synchronization.

The IAM architect’s dream is to have the person’s name bear no relationship to any of those other fields.  In which case a rename might not be a large operation.  Good luck with that.  I’d try and fight to have the MBUNs and common name be unrelated.  If that works you can try for the credentials.

Regardless of how stand-alone the name is you still need to keep the spectre of renames in mind as you create your provisioning processes and every time you link you system to another and with every application that leverages your IAM system.

Even if you have all those separated you still need to keep renames in mind.  Will any of your MBUNs or credentials or common names ever need changing for any reason.  And business logic may still rest on the given name and surname.

And don’t forget approvals and logging and all the other usual subjects in your rename process.

Disabling the Account

Not a lockout and not a full deprovisioning just preventing the account from being allowed to use the IAM system.  This process should be pretty simple to implement by this point.  The same concerns for approval and logging apply.

The big question is “why?” – Why would you disable an account?  Perhaps it has gone inactive.  Perhaps it seems to have been under attack.  Perhaps it is a stage in executing another process.  Perhaps someone is going on leave.  Perhaps new accounts are initially placed into a disabled state until the person performs a verification of registration.

And once you know why the next question is “for how long?”  Disabled accounts are a security risk.  They can always be enabled and they are not under active use.  So a disable should eventually result in a user contact or a deprovisioning.

Every other data piece in the IAM system

They all might need changing or correcting.  A process needs to exist for each one – and you thought it would get easier.  They key question is will the change impact business logic?  If so, then you need to explore what the impact is and would your process need to consider it. If not, then it is simply approval and logging.

Other data may also have a need to keep versions of the old data, or privacy concerns.  Just take some time to look at every piece of data.

Examples of data common in an IAM system include: titles, phone numbers, addresses, e-mail/IM/other contact methods, organizational info (business unit, supervisor, etc.), identity proofing info, enrollment info.  We’ll consider roles, groups and other access information separately.

Also remember to create standardization or normalization constraints for each of your data fields.

Logging/Auditing

I talking a lot about logging and auditing.  I’ve said that you need to log all your processes.  Specifically we can be thinking of two different places – automatically by the IAM system, in your change management sysem, or into fields of the IAM system.

More questions to ask?  Sure.

What do you want to audit?  all object changes, all authentications, all authorizations, access to individual systems?  What can your system log?  How will you collect the data?  How will you confirm its authenticity?  What detail do you need in the logs?

And more!  What are you planning on doing with these logs?  What audit requirements must you fulfill?  Are there legislative requirements?  Do you need to adhere to a standard like SOX (or a similar Canadian statute)?

Now how do you manage the log?  Where is it stored, does it need rotation?  Do you need to roll it up into summaries and reports?

Anything else?

Well – only everything you need to run any generic system.  Backup, restore, redundancy, performance and capacity monitoring, the role in DR and BCP.

We are getting so close to the end now!  One last piece of advice.  Things can also be overanalyzed.  Keep your system in perspective with what it is protecting.