Sometimes I want to simulate connectivity from an application another way, usually for troubleshooting or verifying networks and accounts have been set up correctly. One thing that’s always been difficult is testing I can connect to a SQL database in a non-trusting domain, using an AD account in the other domain. I can’t hardcode credentials in…
Author: Carol
IAM Design Principle: Handle Non-Standard in a Standard Way
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…
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…
IAM Design Principle: Use your IAM platform for IAM work
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…
Setting up SharePoint Foundation 2013 for MIM 2016 SP1
It occurred to me while fighting with this over the last couple of days that I have never installed the MIM Portal in anything other than a lab. FIM Portal yes, but then only on SharePoint 2010 (even after 2013 was available, because it was a heck of a lot easier). While I know MIM…
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…
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…
IAM Design Principle: Don’t make decisions on an absense of data
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…
IAM Design Principle: The Source of Truth is the place where people care about the data being right
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…