I am reading that roles in FIM can be managed by setting Groups or by adding a new Role Object . It seems that creating new Role Object requires much more customization. What is Microsoft’s best recommendation for managing roles in FIM? Here is the scenario we are trying to implement: We have three primary user types: Student, Faculty, and Staff. There are also other user types. One user can have multiple roles. For example a person can be Student, Staff, and Faculty at the same time. Staff and Faculty have access to Employee Domain and can have different access to resources like databases, computers, distribution lists based on department or type of work they do. Students have access to Student Domain and can belong to different class courses. Also everyone has a record in SQL relational database something like User table and UserRoles table (1-to-m relationship). So I was wandering what is the best way to configure user records with multiple user roles like our scenario in FIM? Thank you in advance for any help.

The question of roles and how they are used will be critical to what path you follow. What is the value of the role object? The role objects, in my general definition, would contain a list of accesses that are available to each applicable role. The objects themselves may be linked to the user as a reference value however, unless you're getting into complex application access and provisioning rules that you want to have defined and managed within the object. To me, within a similar scenario I defined the roles in a couple ways -> 1. Attribute based which had two attributes assigned per user. The first attribute was the primary role and the second one was a list of all the roles a user was assigned. For example, a person could be a student, faculty or staff user however, the faculty role was identified as being precedent over all others therefore the primary role was faculty. Applications that didn't care about primary role could simply validate whether or not the appropriate role was in the MVA that listed all assigned roles. 2. Group based. Some systems just like to work better with groups and this is pretty easy to manage within FIM. Simply by putting criteria based groups in place where role value is present, allows a list of valid users to be created. (Also handy if you're mail enabling and want to send an email to everyone with a particular role). Anyway, my $0.02 worth. Thanks B

Thank you for your reply. I am thinking to use the group based roles implementation. I am planning to create a custom attribute for the user resource to represent the list of user roles. This attribute will also determine membership for the criteria based groups. I am wondering if there is a way to specify which role is in which department since roles will be in a list. How do I say he is a Student in the Music department, and Staff in IT department, and a Faculty in Computer Science? May be it is possible to create a specific set of attributes for every user role somehow? I am new to FIM and I don’t have an idea how can I lay this out for multiple user types.

You are quickly moving into the territory of a relational database which FIM is not. In order to define a relationship between a given role and a department you need another reference or link. This is easy. What's not quite so easy is utilising the data, i.e. making these relationships meaningful. You'll quickly find you have lots of activities that cascade string information from one resource to another referenced resource, etc. You might be better off implementing a true, normalised relational database and consuming that, via unnormalised views, and using that information in FIM for criteria-based membership filter definitions. I've gone down the road of implementing RBAC in FIM and other systems and managing the roles in FIM and it's been a real nightmare. In hindsight I should have done it all in SQL, pushing data into FIM and possibly allowing AuthZ based changes to move back into SQL. But I digress. Create a Department, or OrganisationalUnit resource and define a link between a role and an orgUnit, e.g. ParentOrgUnit. I have done this. :)

I wouldn't like to have a nightmare with managing roles :) Would you have any hint on how to flatten the roles implementation?

On Tue, 16 Nov 2010 23:17:01 +0000, ssbobkova wrote: I wouldn't like to have a nightmare with managing roles :)? > Would you have any hint on how to flatten the roles implementation? Another possible solution you might want to look at is the BHold products: http://www.bholdcompany.com Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca

I've gone down the road of implementing RBAC in FIM and other systems and managing the roles in FIM and it's been a real nightmare. I would say: its not a nightmare if you have a RBAC processes described before you started and you can handle two or more CSObjects from one MA linked to one MVEntry, or if you can manage 2 AD MAs pointing to the same domain, or you can link one CSEntry to several MVEntries (which is not supported by design) :)