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 proscribed 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 principal 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Â configuration thatÂ allows/ignores/incorporates the manual stuff.
This will, in all likelihood, involveÂ process changes outside the IAM solution. Manual changes must be seperated, 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.