Resources For IT Professionals
Page Details
  • First published by (fMicrosoft Partner, Microsoft Community Contributo)
  • When: 22 Jul 2011 4:10 PM
  • Last revision by (eMicrosoft Community Contributor, Microsoft Partne)
  • When: 9 Apr 2013 12:06 PM
  • Revisions: 18
  • Comments: 1
Options

Revision #8

Wiki  >  TechNet Articles  >  FIM 2010: Use Sets and Groups as Enterprise RBAC System  >  Revision #8
FIM 2010: Use Sets and Groups as Enterprise RBAC System
You are currently reviewing an older revision of this page.
Go to current version

Enterprise Roles:

Within an organization, enterprise roles are defined based on some business employee's criteria such as title, job level, department, etc. those roles represent group of permissions and responsibilities granted to the user to do his job. Most of our work today is digitized; we interact all the time with different software applications in order to do our job.

Each enterprise role can be viewed or split out to child application roles representing the applications the employee works on, each application role contains permissions to carry out tasks into that specific application. But most of the time there's no direct assignment between the user and the permissions; instead the assignment is between the user and the application role.

FIM in-box features do great work in mapping logical business rules to FIM technical triplet-model (MPR, Workflow and SR), which will satisfy most of the needs an organization ask for, FIM does a great job when it comes to provisioning different objects such as user accounts to enterprise systems by communicating with their back-end stores such as LDAP-directory, Database, CSV files, etc.

So FIM plays well when dealing with application roles lifecycle management, but what about enterprise roles, as I described we can look to the enterprise role object as a collection of application roles, in enterprise RBAC system we need to manage those supersets.


FIM as Enterprise RBAC

Luckily FIM has different levels of extensibility, using schema extensibility area we can extend any object, so no need to reinvent the wheel we can use the existing object in FIM OOB and enhance their functionality.

One object we are after is the SET object, it's used to define collection of objects with some criteria, and we are going to use the SET as our enterprise role object, on the other hand GROUP makes a perfect candidate to be used as application role.

At first we need to extend the SET object and add custom multi-value reference attribute called "ApplicationRoles", this will hold the references to the defined Group (aka the application role).

FIM groups (application roles) are generic; we need a way to differentiate the target applications, in order to do that we need to extend the Group object by adding custom single-value string attribute "TargetApplication".

The next step is defining the application roles in FIM by creating manual-membership Groups and filling the TargetApplication attribute. After doing that we define our enterprise roles in FIM by creating SETs and adding the related application roles to the "ApplicationRoles" attribute. In SET definition we can create our enterprise role criteria-membership (manual membership scenario will be handled in different article).

Now having users defined as members in our enterprise roles (SETs) , we also need to add the user to the application roles defined, another extensibility area in FIM is creating custom action workflows, simply we can create an action workflow that reads the application roles defined in the SET, iterate through them and add the user to the "ExplicitMember" attribute.

Thus we can define a transition-in SET MPR, in action workflow, we create workflow parameter "EnterpriseRoleDisplayName" using FIM FunctionEvaluator activity, in this workflow parameter we write our current ERole's displayname, then we add our custom built activity that handle assigning roles membership.

Half of the work is done, now we define our logic to synchronize application role's members into the target application (using our defined FIM groups), some target applications is straight forward such as Active Directory (since its one-to-one group relation), other applications might need some custom connector in order to parse the role members and export them in the correct record format.

Revert to this revision