Next in my “Five things about FIM” posts – five things I have learnt about Management Policy Rules.
They give permissions, to a Set or referentially
The first thing I understood about MPRs is that they give permissions within the FIM Portal environment. There are various MPRs that come pre-configured to give permissions to the Administrator, the Built-In Sync Account, and Portal users – and a number of them have to be enabled before you can get going.
Permissions may be granted to Sets, where a Set is a group that exists solely within the Portal. You can’t specify a single user here, but I think most people would agree it’s better to grant permissions to groups instead of individial users – even if this means creating a set with a single member.
Permissions may also be granted referentially, where you choose an attribute of the person currently making the request through the Portal, and apply permissions to that. The attribute selected would have to be the Reference data type, such as:
- ResourceID – permission granted to the person to act upon their own profile,
- Manager – permission granted to the person’s manager,
- Assistant – permission granted to the person’s assistant.
The rights change straight away
I really like the way permission changes are applied immediately, and without any need for an iisreset.
And I particulary like the way the View and Edit forms change accordingly – attribute names are removed from the view of users with no rights to them. Unfortunately this is not the case for the Create forms, where the only way you can completely remove a field is by editing the underlying XML. (I asked about this on connect and was told the Create forms will self-modify in a future release.)
Rights are cumulative and there’s no “Deny”
Still on the permissions side of MPRs – you can only give rights, you can’t block them. All permissions are assumed to be not allowed unless explicitly granted.
The lack of Deny is probably a very good thing as we could easily end up with multiple MPRs applying to a user. At least this way we only have to worry about the permissions that have been granted, without the possible complication of over-riding denials.
They also trigger Workflows
As well as applying permissions, MPRs trigger Workflows. Some MPRs just grant permissions, some just trigger workflows, and some do both.
At first I found this hard to understand, because permissions and workflows are completely different things. But after creating a few it’s starting to make more sense. It means that you tailor your MPRs to specific events you expect to happen, such as:
- When the Built-In Sync Account imports a new person object from the Sync Service (with permission to do this) a workflow should run to generate some extra attributes (tack on an Action workflow).
- When a user requests an account for a contractor (with permission) seek approval from their manager, and then generate some extra attributes (tack on an AuthZ and an Action workflow).
MPRs can also trigger workflows because a value changed. In some MPRs this can be any change; in others the change causes the object to move from one Set to another. So perhaps the Department changed, causing the person to move from the “All People in HR” set to the “All People NOT in HR” set. (When you create a Set for MPRs, you usually have to create the opposite Set as well.)
I worry about keeping track of them
You can call an MPR whatever you like, which of course means you are free to be as tidy or as messy as you like. As I’m yet to play with FIM in anything other that a test environment I have no idea what it will look like with a couple of hundred MPRs defined. Clear naming for searchability and ongoing management will be important.
What I would really like is a utility that shows you all the MPRs that apply to an object – something like this will be invaluable in troubleshooting, especially if it wasn’t you that built the system. Perhaps someone far cleverer than me will write something along these lines.
… UPDATE: and it looks like someone has already done exactly that and I hadn’t noticed! One of Jorge’s very informative posts today has pointed out the new Explore option which should help with this. I’ll have to have a play next time my lab is fired up.
