missmiis

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. Continue reading ›

Integration between IT systems is hard, even when they support common standards, so I understand this desire for a service tool that does “everything”. IAM software platforms are typically extensible in various ways such as scripting, custom schema and custom workflows, so it may well be that you can do something a bit out of the ordinary, but should you? Software is developed with certain uses in mind and trying to force it into some other shape is rarely good for the on-going effectiveness and maintainability of the solution.

Some “un-natural” things I’ve seen people try to do with their IAM solution: handling service tickets, service catalog, access audit in external systems, asset management, general purpose ETL and orchestration, non-IAM aspects of application administration.
Continue reading ›

When collecting requirements for an IAM solution we associate actions with various ways of categorising users – in other words, we are mapping “form” to “function”. When designing the IAM Solution, however, we need to provide a layer of separation between the two. The best way to illustrate why is with a real-life example. Continue reading ›

A field indicating a person’s “status” with respect to the organisation is a standard feature of all IAM implementations. Over many solutions I’ve boiled it down to four status values that satisfy all the lifecycle use cases I’ve come across:

1. Pending – We know about this person but their hire (or re-hire) date is in the future,
2. Active – Active employment or other relationship,
3. Suspended – A temporary state where all accounts are disabled but otherwise unchanged, perhaps due to long leave or temporary suspension of duties,
4. Inactive – Relationship with the organisation has ceased.

The designer of the IAM solution shouldn’t have to be concerned with why a person is in any one of these states – all we need to know is:

• how to identify the status, and
• what to do when the status changes.

Obviously the staus is sometimes combined with other attribute values to determine actions, but these are the four status values I have found to be generally applicable across a range of solutions and organisation types.

I’ve recently started a new project and we’re in the requirements gathering phase, so lots of meetings and discussions, and also (thankfully) enthusiasm for the project.

There’s also been lots of me repeating stuff I always say when trying to explain Good IAM Design, so I’ve decided to start a new series of short blog posts on the subject. There will be some overlap with an earlier series I did on FIM Best Practises, but I’ll be keeping this one product independant. Continue reading ›