none
Add users to groups by workflow RRS feed

  • Question

  • Something I haven't been able to figure out is how to use a workflow to add a user to a group.  Here is the scenario:

    - A custom attribute "Work Site" that contains the users work site

    - A set transition when the user's work site is selected

    What I want to happen, is that if the user's work site attribute is changed to "Site A" then the user is added into a bunch of groups (distribution and security) that relate to Site A.  There are other sites, Site B, Site C etc that also have related bunches of groups.  These groups are, for example, "All staff at siteA" email distribution lists and "Map Printers at Site A" Security groups.

    There doesn't appear to be a type of action workflow that can achieve this.

    I should point out that these Security and Distribution groups are AD groups, synchronized to FIM.  Therefore, criteria based groups would not work as they would lose the manually assigned memberships that were imported from AD.
    • Edited by Lachlan Follett Tuesday, December 4, 2012 9:38 PM Added more info
    Tuesday, December 4, 2012 9:33 PM

Answers

  • The other approach and one I've had to consider is making it all happen within Sets....because you can have the criteria AND the manually managed membership.

    Doing it this way would eliminate the problems or pitfalls you describe, but would require a select group of users (owners) to be placed in a set you use in an MPR to allow that set of "Set Owners" view and control over the set you criteria.  Then flow the membership of the dual criteria and manual membership set to the AD group.  No equal precedence needed...no workflow needed......The risk mitigation for allowing certain set owners to see sets is that you can control which sets they are able to see....basically you are moving the control through FIM of group memberships from AD groups viewed in FIM to the much more flexible Set memberships...

    So...create a set called "Work Site Admins"...the members would be the folks you give permissions to view and manage a limited number of other sets.

    Create a set called...."Work Site Admins Sets"...the member are the sets you plan on giving them permission to view.

    Create an MPR titled..."Work Site Admins can view sets"...requestors is "work site admins" set...Read resource/grant perm....target is either all sets or the "work site admins sets" set.

    create a second MPR or add these abilities to the first mpr...add and update the value properties you need so they can add members...the target is the "work site admins set"

    I split the two for a reason, but you don't have to.

    Don't forget to make sets viewable in the navigation bar resource for those folks....or choose BasicUI keyword. 

    I'm sure I'm forgetting a step that we did, but it works....Only those few people can actually touch a set membership on a set we defined....and now they have proper control over an eventual AD group membership without workflows and without the other pitfalls others talked about here.

    Tuesday, December 11, 2012 2:43 PM

All replies

  • Well .. this type of workflow is in there but it is called "custom". Relatively easy to achieve with custom activity + some process should be in place for housekeeping of such groups (periodically validate with a query if state of a group is consistent with what it should be). It will require to build such activity however - just did it previous week and it took few hours with design and testing in total. 

    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    Tuesday, December 4, 2012 9:58 PM
  • I'm not keen to deploy custom coding for this client as they do not have the resources to maintain it.

    I wonder if I could get around it by cascading groups, e.g.:

    1) Create a criteria based group in FIM e.g. FIM_WorkSite_A

    2) Make FIM_WorkSite_A a member of the manual group (AD group) All_staff_at_site_a

    3) Have FIM export the criteria based group out to AD in the usual way by provisioning

    4) Use the criteria of the group as "Custom_Attribute_Work_Site is Site_A"

    Do you see any pitfalls of this approach?

    Tuesday, December 4, 2012 10:12 PM
  • The only pitfall would be setting the precedence and the rights to change these groups in AD. To be able to do this equal precedence is required. AD and FIM should be able to change a group.

    If the group FIM_WorkSite_A gets another user added in AD the group gets corrupted in FIM. Criteria groups do not respond well to manually added members.

    Tuesday, December 11, 2012 1:37 PM
  • The other approach and one I've had to consider is making it all happen within Sets....because you can have the criteria AND the manually managed membership.

    Doing it this way would eliminate the problems or pitfalls you describe, but would require a select group of users (owners) to be placed in a set you use in an MPR to allow that set of "Set Owners" view and control over the set you criteria.  Then flow the membership of the dual criteria and manual membership set to the AD group.  No equal precedence needed...no workflow needed......The risk mitigation for allowing certain set owners to see sets is that you can control which sets they are able to see....basically you are moving the control through FIM of group memberships from AD groups viewed in FIM to the much more flexible Set memberships...

    So...create a set called "Work Site Admins"...the members would be the folks you give permissions to view and manage a limited number of other sets.

    Create a set called...."Work Site Admins Sets"...the member are the sets you plan on giving them permission to view.

    Create an MPR titled..."Work Site Admins can view sets"...requestors is "work site admins" set...Read resource/grant perm....target is either all sets or the "work site admins sets" set.

    create a second MPR or add these abilities to the first mpr...add and update the value properties you need so they can add members...the target is the "work site admins set"

    I split the two for a reason, but you don't have to.

    Don't forget to make sets viewable in the navigation bar resource for those folks....or choose BasicUI keyword. 

    I'm sure I'm forgetting a step that we did, but it works....Only those few people can actually touch a set membership on a set we defined....and now they have proper control over an eventual AD group membership without workflows and without the other pitfalls others talked about here.

    Tuesday, December 11, 2012 2:43 PM