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 ›
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:
So for each target system I will have a table like the following. The “Lifecycle Events” I’ve listed I think are fairly universal. How you detect them (the “Trigger”), and what actions the IAM solution takes will of course be solution-specific. In some cases the IAM Solution’s action will be “none”, but that should still be documented.
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:
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:
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 been going on about this one for a long time, but in case anyone still isn’t on-board with this principal I’ll state it another way: data disappearing from a feed is not a suitable trigger for action.
When we treat disappearance of data as a “trigger” we are interpreting a root cause from a received effect. We are saying “there can only ever be one possible reason why this piece of data has gone missing from our feed” – but is that really the case? Continue reading ›
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 ›
I presented this at the MIM Team User Group meeting last week, but was having some computer issues and apparently people couldn’t hear me. There did seem to be quite a bit of interest from the comments window, so I figured I’d write it up as a blog post.
This solution allows an Office 365 account to automatically transition from “Synchronized” to “Cloud managed”. It was designed for a university where:
Following are some pictures I put together to present the solution. A licensing process is mentioned but not covered – this just focuses on the change in management source.
It should also be noted that this solution has been in production for over a year.
I’m just going to say it – many people in IT don’t give enough thought to requirements. They might think they do, there may even be a document with the word “Requirements” in the title, but are they good enough for the job?
I worked with the FIMWAL in the past on a couple of MCS engagments, but hadn’t yet had the opportunity to use the open-sourced MIMWAL on an engagment. I have, however, just been converting something I’ve done before to all-MIMWAL workflows, in preparation for re-using the concepts on a new project.
This is a pretty complex “pack” of stuff, including schema, policy and UI. Part of the solution is that new, customised policy objects are generated in response to certain changes made in the Portal. Converting this solution to the MIMWAL has been a lot of fun, and really quite intuitive, with everything I wanted to do covered – and in some cases simplified compared to what I had before. A lot of the workflows I was replacing were PowerShell scripts – I now have only a very small amount of in-Workflow PowerShell left and no external scripts at all.
I had a large CSV of data to be loaded in through the FIM Service. Single threading this operation could have taken (literally) days, so I decided to have a go at multi-threading it, and here’s the skeleton script. Continue reading ›
I recently wanted to do some analysis of existing groups in a well established AD that has a lot of groups (more groups than users in fact). I was hoping to find groups that looked like good candidates for conversion to role-based (aka criteria-based) groups. Continue reading ›
