Wednesday, September 19, 2012

Group Expansion in the FIM Service

The FIM product is full of little features than can be fun to discover.  Just when you thought you knew it all…  Somebody asked me about using FIM Groups as owners of Groups, and I didn’t have the answer so I tried it.
#FAIL.  Turns out you cannot use the FIM Portal to add a Group as an owner of a Group. 
Then I dug a little deeper and tried it directly against the FIM Service (bypassing the FIM Portal, which is really just a client to the FIM Service).  The FIM Service happily accepted the request.  The script and resulting request are shown below.
 
###
### Add a Group as the Owner of another Group
###
New-FimImportObject -State Put -ObjectType Group -AnchorPairs @{DisplayName='testGroup828'} -Changes @(
    New-FimImportChange -Operation Add -AttributeName Owner -AttributeValue ('Group','DisplayName','GroupOwnersGroup')   
) -ApplyNow
 


The interesting thing about the request above is that it shows the type of object in the reference, indicating that we have added a Group to the Owner attribute.
The next thing I wondered is, what happens when the FIM Approval Activity processes a request where approval is required?  We know the Approval Activity refers to the Group owner attribute with XPath syntax, so what is it expecting when it finds a Group there instead of a Person?  Will it freak out and end this experiment?

 
###
### Add a user to the Group
###
New-FimImportObject -State Put -ObjectType Group -AnchorPairs @{DisplayName='testGroup828'} -Changes @(
    New-FimImportChange -Operation Add -AttributeName ExplicitMember -AttributeValue ('Person','DisplayName','newGroupMember1')   
) -ApplyNow
 
The result of this script is actually quite interesting.  The script just adds a member to a Group that requires owner-approval for new members.  This triggers an MPR that fires a Workflow with the Approval Activity.  The Group in question has two owners listed:
1. groupOwner1 (a person object)
2. GroupOwnersGroup (a group object)



The Approval object created by the Approval Activity shows that FIM is expanding the members of GroupOwnersGroup and placing them into the Approval as Approvers.  Pretty cool.  So the FIM Service expands groups for approval activities similar to how Exchange expands groups for mail delivery.



The moral of the story here is that the FIM Portal is really just a client to the FIM Service, and that scenarios may be closer to working than the portal will have you believe.  In this case, I bet the Group RCDC can be modified to allow you to select Groups as owners, and the whole thing will probably work.  Probably.  The pessimist might wonder why it isn’t this way already in the product?  Is there a bug lurking in there that my little experiment dodged somehow?  Time will tell.  I know I’ll be looking into this a little deeper and writing a few test cases for it.

Does it work with Nesting?

Somebody responded and asked if this still works with group nesting, so I tried that too.  I added another group with two members, then added the new group to the scenario above and the Approval Activity still expanded all the way to the nested group’s members.

1 comment:

Unknown said...

There was a change in one of the FIM 2010 (pre R2) QFEs that enabled this - the service used to block it IIRC.