Share via

Enterprise Roles in Microsoft Forefront Identity Manager 2010 (FIM)

  • Article

Overview

An often discussed topic in Identity Management is Role Based Access Control or RBAC.  When discussing Forefront Identity Manager 2010 (FIM), this is no exception.  This blog discusses role management and how basic RBAC can be accomplished in FIM at a high level.

What is a Role?

Organizations define roles at varying levels. From and LDAP perspective, roles are collection of users. From an organization perspective, roles are often associated with any of the following: (1) responsibility, (2) job function or (3) application access.  Roles can be formal, such as “HR representative”, or informal, like “Event Response Team”.  Roles can be determined for a Source of Record (SoR) or adhoc. Sometimes roles are hierarchical; other times they are expected to not be.  Roles can be inclusive or exclusive, meaning they can grant or revoke permissions.  Lastly, roles can have multiple dimensions in its criteria, such as:

  1. Is a full time employee
  2. Is in North America
  3. Has direct reports
  4. Is not in the finance department name
  5. Reports up to cost center 1585
  6. Has completed application training

One key aspect of roles is that they are what permissions are assigned to and not the user’s account.  Roles also define user membership, therefore granting users the application level access that is needed.  It follows a modified form of assigning permission such as:

User -> Role -> Permissions

There is also a more common role structure that grants greater flexibility and could be hierarchical:

User -> Enterprise Role(s) -> Application Role(s) -> Permission(s)

For this document, we will consider roles as “a collection of objects that have entitlements”.  In simple terms, this means determining and grouping users to grant access.

What role functionality does FIM have “out of the box”?

FIM come pre-configured with a role defined in the synchronization engine and “Sets” and “Groups” in the portal. 

Set are defined as “A collection of object references defined by a filter or selected manually”.  By default there are 73 pre-defined sets in FIM 2010 RTM. Sets can:

  • be static or dynamic
  • have a workflow associated
  • grant permissions in the FIM portal
  • be associated with a FIM Management Policy Rule (MPR)

Groups are more common in most systems, and are often where permissions are granted.  In FIM, groups can:

  • be static or dynamic
  • have user approvals associated
  • have a workflow associated
  • be projected or associated with groups on managed systems, such as groups in Active Directory
  • allow uses to request access via the Microsoft Outlook client
  • have an expiration time (for the group, not user membership)

Each of these objects can be extended, and you can even create your own “MySet” or “MyGroup” schema object to facilitate additional functionality that Sets or Groups do not provide out of the box.

To be clear, Sets and Groups lack the following functionality “out of the box” often found with role objects:

  • separation of duty
  • support for hierarchy
  • attestation
  • expiration of user membership based on time

So can FIM handle all of my Role needs?

Perhaps. If your needs are pretty simple and groups or sets can meet your needs with little or no “configuration”, then yes.  Examples might include:

Role Name Role Logic
All Employees All users where EmployeeID is not null and employee status is active
All HR Employees All users where JobCode is in (100,200,300,400) and employee status is active
All North America Employees All users where CountryCode is US and employee status is active

These roles are pretty simple and easy to setup in FIM.  If you have only a few roles, then I would say “yes, FIM can handle your role needs”.  If you have thousands of roles or complex multi dimension role logic, then I would say that managing roles in FIM will not be in efficient.

If you have additional needs of roles, say:

  • attestation (periodic review and certification)
  • complex reporting
  • complex regulatory needs
  • complex separation of duties needs
  • multi dimension needs

FIM roles might not meet your needs and you will need an additional role solution.  Just mapping your role needs can be difficult enough, requiring an advanced role solution, either custom built or partner provided.

What partner solutions exist?

Omada

Omada provides a new, innovative, template-based solution for Role-Based Access Control and Identity and Access Governance. It is completely integrated into and designed for FIM from the ground up. Omada’s advanced software modules for FIM optimize project success by eliminating the time and risk related to custom development while reducing the Total Cost of Ownership through continued support, maintenance and product enhancements.

Omada Role-Based Access Control for FIM offers an advanced feature set for managing roles. It significantly improves security and the administration of users’ access rights in large, heterogeneous networks, including advanced connectivity to ERP systems such as SAP. This role management solution is fully supported by Omada compliance modules, providing in-depth auditing, compliance reporting and attestation on roles.

Examples of features in the Omada Role Engine are:

  • -  Support for hierarchical role models, applying advanced concepts such as role attributes and criteria-based assignment of child roles and permissions
  • -  Support for automated role assignments based on multiple business hierarchies such as departments, cost centers, projects, locations, etc.
  • -  Graphical ‘drag and drop’ design and configuration of roles, rules and policies
  • -  Point-in-time inspection of who had access to what and when
  • -  Application of time constraints on roles, employees, rules, assignments, etc.
  • -  Advanced concept for Segregation of Duties

Omada is the 2008 and 2009 winner of the Microsoft Worldwide Partner Award for Identity and Secure Access and has for many years provided Role-Based Access Control for large, global organizations. Learn more at www.Omada.net.

bHold (Recently purchased by Microsoft and included in FIM 2010 R2)

BHOLD Suite - for prevention

BHOLD Suite is a structural and real-time solution for role-based access management. Organizations no longer have to make repeated attempts at tracking down and resolving recurring security issues. Instead, issues are prevented upfront. BHOLD Suite provides for the prevention of unauthorized access. The application avoids conflicts in the segregation of duties, as well as preventing people from getting around Chinese walls and personnel from piling up access rights unchecked.

Manage your employees access rights

BHOLD Suite offers a complete management suite for auditing, reporting, attestation and simulation. The application keeps a reliable log of authorizations and roles. BHOLD Suite integrates seamlessly with Microsoft's SharePoint-based user interface for self service and workflow.

Competitive benefits

Using BHOLD Suite generates enormous competitive benefits: it improves efficiency, effectiveness and productivity as well as cutting costs. In addition, the application ensures that IT remains flexible in respect of organizational changes and collaborative business models that give suppliers access (or temporary access) to all or part of a company's IT system.

Role management for Forefront Identity Manager 2010

BHOLD Suite is a powerful application for control of authorization management, for use in conjunction with FIM2010.

What about building my own RBAC solution outside of FIM?

This is definitely doable. In fact integrating partner and competitive solutions can be as simple as reading and writing to a SQL table.  Following this integration approach, the external RBAC solution is the engine that determines when a user should be granted access, and FIM performs the task of granting access.  With this loosely coupled architecture, you can write your RBAC solution in any language or platform, as long as it can produce consumable content and the schema of the content is known by FIM.

How can I implement a “Role” object in FIM?

So you have decided not to use a partner solution and did not want to code your own outside of FIM?  Good news for you, FIM, with configuration and coding can do this. I will provide some general guidelines below, but implementation is at your own risk and based on our understanding of FIM.

If your goal is to have a SoR determine what roles a user should have…

If your SoR provides roles as an attribute of the user, this can be as simple as adding an attribute to the user object in FIM and setting up groups to look at this attribute.  Example, if your HR system say user has role “banana” then add that value to the user and setup a group in FIM based on that attribute.  This can allow for multi dimension roles.

If your SoR has a role object as an independent schema object, then you can match the role object to a group object and have FIM populate the user membership based on SoR data. This does not allow for multi dimension roles, unless you use 2 type of roles, 1 from the SoR (we will call those Enterprise Roles) and 1 for the resources (we will call those Application Roles).

All reporting, membership changes, separation of duties and attestation for these roles takes place in the SoR.

If your goal is to have roles as a standalone object in FIM….

In this approach, you create a “role” and “SeperationOfDuty” resource type, all the attributes needed and the bindings.  You will also need to add attributes to the existing user resource type, create management policy rules, sets, workflows and a design UI.  Consider the following attributes for the role:

Attribute Name Description
DisplayName Human readable name
RoleType Type of role, enterprise application, other
SystemName Name of the system the role applies to. Could be multivalued.
PermissionName Permission level the role applies. Could be multivalued
Roles Roles are directly included by this role
Members Static membership
MembershipSet A set that defines the dynamic role membership
RoleOwner Who approves static role membership or is notified of MemberLogic changes
RoleWorkflow Name of any workflow associated with this role
RoleApprovalDate Date the role was last approved / reviewed by the role owner.
EffectiveMembers List of direct and indirect user members (a special MPR with workflow updates this and SOD verification)
EffectiveRoles List of direct and indirect role members (a special MPR with workflow updates this and SOD verification)

Consider the following attributes to add to the user resource type:

Attribute Name Description
Roles List of roles this user is assigned to
RoleApprovalDate Dates (matching Roles attribute) that the role membership has been reviewed
TextualRoles Human readable role list.

Consider the following attributes to add to the “SeperationOfDuty” resource type:

Attribute Name Description
DisplayName Human readable name
Roles List of 2 roles that have a SOD conflict

Now we have the major schema objects, let’s discuss a way to make them all work, focusing on MPRs and workflows only. 

Option 1 – update via the user object, roles attribute:

We will start from the user object. If we add an entry to the user [roles] attribute this executes a MPR. This MPR checks the role added and the existing roles.  If there is not a SOD conflict, it updates the role object, which follows any normal role MPR process – see option 2 for the normal role MPR.  Lastly the MPR executes a workflow that update the [RoleApprovalDate], which is used later for attestation.

Option 2 – update via the role object:

We now start from the role object. If we add a user to the [members] attribute of the role object this fires a MPR. This MPR checks the user being added and the users existing roles.  First the role is checked for a SOD conflict. Second the [RoleOwner] is notified and asked for approval.  If approved, it updates the role and also updates the user’s [roles] attribute.  Next the MPR executes a workflow (default or value of [RoleWorkflow]) which will provision the user to the resource [SystemName] and grants the rights [PermissionName].  Lastly, the MPR executes a workflow that updates the [EffectiveMembers] value.

Option 3 – update via the user object, other attributes

The reason we have a [membershipset] attribute as opposed to [members] is that sometimes a role can be dynamic, and FIM already has the ability to execute workflows base on set changes.  In this case, say we change the attribute jobCode of a user to “26”.  When you create a role that has a [membershipset], this can create a MPR that is triggered on “Set Transition” that will execute either the default role workflow or the value of [RoleWorkflow].

Also associated will be attestation processes, for both roles and users, based on the [RoleApprovalData] of the role and the user.

Source

Much of the information presented in this blog was based off the prototype and demonstration by Jan Macherzynski at the 2009 The Experts Conference in Europe (http://www.tec2009.com/berlin/agenda/directory/session_abstracts.php).

Authors:

  • Kevin Saye, Forefront Technical Specialist, Microsoft
  • Jan Macherzynski, Architect Consultant, Microsoft