Request group membership only for myself RRS feed

  • Question

  • Is there an easy way (i.e. without custom workflow) to authorize a group membership request in the following way:

    - a user can request group membership only for herself and noone else

    With an MPR, I can say that a user can request group membership for all other users (e.g. "Security group management: Users can add or remove any member of groups subject to owner approval"). With this MPR I am defining All Active People as Requestors and Owner Approved Security Groups as Target Resource. What I would like to achieve is that "the Requestor is the MemberToAdd".

    Thanks in advance.

    Tuesday, March 12, 2013 8:11 PM

All replies

  • I am going to bite the bullet and say NO.  However as soon as I say this I expect some bright spark will refute it :).

    The type of MPR you would need to consider would be a "relative to resource" MPR, but you would need a binding on the target object class (group) to include the MODIFIER, but we only have Creator (and this is the creator of the group and not the request).  I am thinking perhaps you could create a custom binding of your own (say Group.Modifier) and set this value in the AuthZ workflow step using the Function Evaluator (set it to //Creator) and then see if that works for you, but my expectation would be that this would probably be too late in the cycle.  Still, you could give this a try easily enough and let us know if it works.

    An idea to consider might be to use RCDC scoping to only allow the user to add themselves as a member.  While this is not infalible (i.e. a custom FIM client could get around this) it might be manageable, although this would impact all users across the board.

    Bob Bradley (FIMBob @ ... now using Event Broker 3.0 for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    Tuesday, March 19, 2013 8:42 AM
  • I have tried various approaches to achieve this. The fact is, that it cannot be done with an MPR, but has to be done in an authZ workflow. This means that from the GUI point of view, the solution is not perfect (i.e. I will get “Access denied” error after submitting the request, then I have to click on details to get the real reason, then I cannot re-use the failed request and have to start creating the request from the scratch – but this is another topic). So, the approaches:
    1) I tried using a function evaluator activity in the authZ workflow. I can use following custom expression IIF(Eq([//Delta/ExplicitMember/Added],[//Requestor/ObjectID]),"Requested membership for himself","Requested membership for someone else") to compare the requestor with the member to add. But, I can only write the result in a target attribute (or pass it to another activity). What I want to do is to abort the workflow and say “Access denied, because of this and that”. This seems not to be possible with out-of-the-box activities. So this approach failed.
    2) Use the Code Run custom activity: Here I can use similar comparison as in 1) with the difference that I can throw an exception out of the code which causes workflow to abort. The exception message will be used as the failure reason. This approach works, but it is not much simpler than implementing a dedicated custom workflow.
    Any comments?
    • Proposed as answer by UNIFYBobMVP Thursday, August 13, 2015 12:10 PM
    Tuesday, March 19, 2013 11:44 AM