0

IAM Design Principle: Handle Non-Standard in a Standard Way

Share this content:
LinkedIn
Facebook
RSS

The “ideal” IAM solution would have a reliable flow of pre-checked data and a list of sound, proven business rules from which to provision all the accounts and access each person needs to do their job.

This is a fantasy.

The types of work people do, and the IT landscape they do it in, are increasingly fluid and, while we might be able to make “broad brush stroke” access rules, there is still going to be a percentage of access that must be requested, special user accounts that don’t fit the prescribed mould, and genuine emergencies. Our IAM solution must be designed with this expectation.

I could go into a lot of detail here about different methods such as scoping, manual overrides and integrating request-based access – but I’ll leave that for other posts and stick to the fundamental design principle here – which is this:

When designing our IAM solution we must always be considering, and including requirements for, the non-standard. The IAM solution must include a configuration that allows/ignores/incorporates the manual stuff.

This will, in all likelihood, involve process changes outside the IAM solution. Manual changes must be separated, or tagged, in a standard way. Details will differ but there still needs to be a standard way to identify and track the non-standard. This is the only way that automation can work effectively in our dynamic IT environments.

Carol Wapshere

I’ve been working in the IT industry for rather a lot of years now, starting in sys admin then moving through project work and consultancy, eventually coming across MIIS 2003 in 2005 while working on an email migration project in London. After a few years in Switzerland I am now back in Australia, based in Canberra, working for UNIFY Solutions. I have been awarded the MVP for ILM/FIM every year since 2009.

Leave a Reply

Your email address will not be published. Required fields are marked *