The single most important concept about FIM to understand, and to make sure that others involved in the project also understand, is that it is state-based. What this means is that we only care about the current state of the data, and the future state of the data, after we’ve applied our rules. Most importantly, we should not need to know how the object got to its current state.
Sometimes people say things like this: I understand FIM will reverse changes made in my system when another, precedent source exists but if the administrator makes a change, then it should remain.
No.
We could probably write some crazy code or script to rig things so this “requirement” can be met, but it’s not a good idea:
- Troubleshooting will be complicated,
- Blocking flow at an attribute level may be impossible so you’ll have to block the whole object,
- FIM will appear to be unreliable, updating some objects and not others,
- Clearing and reimporting the connector space may produce unexpected results.
Trying to twist FIM to compensate for bad data management practices never works out well in the long-term. So work with FIM’s state-based nature, and make changes around FIM as necessary.
“Most importantly – we should not need to know how the object got to its current state.”
Sorry, but from my perspective this is wrong: we do have to know how the object got it’s current state. We also need to know, what was the previous state of an object.
What do we need to know that for? First of all for audit purposes. A “real” IAM solution should be able to track changes from the sources to the targets. As an second reason we do need to the source of an changed attribute as well as the attribute change itself to have the answer on the overall question “where is that object changed triggered from?” I’ve had several customer situation in the past having not only one source system for an Identity but having multiple sources populating attributes for a single Identity and it’s entitlements (or user accounts) in connected systems.
But starting from “Sometimes people say things like this: “I understand FIM will reverse changes made in my system when another, precedent source exists – but if the administrator makes a change, then it should remainâ€.” till the end of the article, it’s not only FIM, it’s the same “problem” with each other IAM solution out there.
Nevertheless this is the way FIM works so if people are working with it they need to understand this point.