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.

some features of FIM can be applicable for simple scenarios, while complex scenarios need advanced roles manipulation, this superior article shows how to implement advanced Roles as separate objects in FIM, but sometimes our requirements are between, we need something quick that do the job.

FIM SET and Group 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 objects 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, we can easily attach owner approval workflow OOB.

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 or/and manual membership.

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.