I've been trying to figure out a plan for RBAC using FIM. After much research and trial and error, I had unfortunately decided I would have to set it up like this: On the user edit page, allow admins to add roles to a user within a mult-valued roles attribute. Each role would correspond to a Set, which is then the criteria for a Security Group. I would have to set up a Workflow for each set/group, and a corresponding MPR to run that workflow for each user who enters a specific role Set. I currently have the MPR as a request type, not set transition since Authorization Workflows are not allowed in Set transitions. Right now it appears that each request begins one request, which means one approver - not the multiple approvers like I wanted. Is it possible to have each value within the multi-valued attribute approved by their owner? If I create a custom action workflow that was really an approval step, could I divide the request into two separate approvals? How else can I set this up from the user edit pages? We want to have the admin be able to open a user, and assign them roles - but they need to be able to choose from 0-100+ roles, which will only grow over time. If they pick 2 roles, 2 approvals are sent out - one to each owner.

why not use FIM groups as Role object, group/role owner can add members manually or based on criteria, or you can have other authorization workflows for the groups; thus each group/role will have an approval workflow when member is added.

I started out going down a road like that, but we wanted to be able to add users with criteria AND manually (through the user screen and through the group screen, like AD allows) - so I had to use a Set instead.

This is a really complex situation and I'm not entirely sure you'll be able to get it working the way you want to. The approval is really only designed to be setup for the manual memberships for the group objects. I have never ever tried to apply it to a criteria based set because, by the nature of the attributes themselves, you have defined the role. In regards to the manual setup, we have been recently playing with code that would actually push the manual membership to an attribute, parse the new members automatically, send a separate request via the web service (so that approvals and such would take effect) and remove the member from the "pending members" list. Certainly not ideal. I suppose with the criteria based membership, you could parse it and capture the differential but I'd really have to dig around on that... Thanks B

fimTech I like your approach, and speaking from experience of one who has successfully achieved RBAC with FIM along very similar lines as you, the key to our success was something like Blain has referred to in the second paragraph above ... In our case admins maintained a set of multi-value role attributes bound to a user, just like you have, but unlike you they could not do this directly - in fact ALL the multivalue role bindings were read-only. Instead they maintained a set of single value bindings (including a "pending role member") on the person which triggered an approval workflow. The attribute that was the new member was only added on approval ... and this, together with the others that served as context for the role (e.g. justification text for the apporval workflow, membership effective to date, etc.) were cleared on approval (of course they were also cleared out if not approved too - by default). This way you got a full audit history of the request approved and declined requests. The key to this was forcing only one role to be added (of each type) at a time. In our case we had 4 role types (one tab for each), and allowed up to one of each type to be added in the one request ... with 4 separate MPRs governing each. Existing role memberships for each type were displayed in a list control, and below that a UOCIdentityPicker (SingleValue) was used to select the new (pending) role membership. Text boxes were used for the additional meta data relating to the role assignment. This leads to the other key to the success of the RBAC design - a custom resource type "userResource", which captured all approved user role assignments, together with the info entered in the request (effective from/to date, justification text, etc), as this allowed for reattestation workflows to be triggered via a temporal set - 10 days out from the effective to date. This allowed each role membership to have its own unique re-attestation cycle, rather than forcing all role members to have exactly the same cycle (which is the standard FIM model). Of course none of the above was possible without a couple of custom workflow activities which maintained the userResource resource type, together with the management of the user bindings themselves. By adopting the same approach you should be able to achieve the outcome you are after, but accepting that each additional role association (of the same binding) will have to be done in a separate request. This of course means a little more effort is required to set it up, and writing a couple of custom activities (if you design these effectively, you should be able to get the extensive reuse we were able to). Sure it would be nice to be able to add an indefinite number of items at a time ... and indeed you should be able to extend the above idea so that you can add multiple "pending" roles in a single request (by defining the approval workflow on the creation of the userResource object, rather than on the person object like we did). However I would recommend you get the above model working first before looking to extend it. Good luck :) Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

in regards to manual membership to solve the approval issue you can try this: at first make sure you create two multi-value attributes on users (pending-roles, approved-roles) have a request-MPR which update the pending-roles on the user to run custom action workflow to parse the request parameters, add the added role values to array, then loop through the array to update the corresponding members attribute in the role(SET or Group) - using WhileActivity and UpdateResource - don't use the FIM service account as the Actor in the UpdateResource so AuthZ workflows will be triggered your role (SET or Group) should be configured with an MPR which run owner approval workflow, and have an action workflow activity to write back the approved role to the approved-roles of the user. sorry but I did not test the above yet ... good luck

Yes Amer - you are right to point out the actor consideration. This would also be required if you were to extend the idea I described above where the approval workflow would fire on the creation of a userResource object. Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine