Author: Carol

I've been doing IT for 30 years, and IdM for 15. I live in Australia and build IdM solutions based on Microsoft Identity Manager. I also play the violin, but that doesn't help much with the IdM solutions.

IAM Design Principle: Plan for data errors

Automation isn’t just about replicating an existing manual processes. Yes we want the same end results, but the process will have to be different because it’s a dumb computer doing it and not a human. Humans are really good at spotting patterns, including ones we’ve never seen before. A human operator will be able to
Read More »

IAM Design Principle: Separate form from function

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.

IAM Design Principle: Lifecycle Events

I’ve really been trying to improve my skills at capturing and writing up requirements and one thing that helps is to list all the typical identity “lifecycle events”, along with: How to detect the event, and What to do when the event is detected. So for each target system I will have a table like
Read More »

IAM Design Principle: User Status Values

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: Pending – We know about this person but their hire (or re-hire) date is in
Read More »