Introduction to administering Microsoft BHOLD FIM Integration

Applies To: Forefront Identity Manager

Microsoft® Forefront Identity Manager 2010 R2 (FIM) enables organizations to manage the entire lifecycle of user identities and their associated credentials. It can be configured to synchronize identities, centrally manage certificates and passwords, and provision users across heterogeneous systems. With FIM, IT organizations can define and automate the processes used to manage identities from creation to retirement.

Microsoft BHOLD Suite extends these capabilities of FIM by adding role-based access control (RBAC) to FIM, enabling organizations to define user roles and to control access to sensitive data and applications in a way that is appropriate for those roles. BHOLD Suite includes services and tools that simplify the modeling of the role relationships within the organization, map those roles to permissions, and to verify that the role definitions and associated permissions are correctly applied to users. These capabilities are fully integrated with FIM, providing a seamless experience for end users and IT staff alike.

The BHOLD FIM Integration module of the Microsoft BHOLD Suite SP1 adds to the FIM Portal the ability to manage the assignment of BHOLD roles to users. By using the BHOLD FIM Integration extension to the FIM Portal, a user can request the assignment of a role, and a user who is a designated role approval can respond to role assignment requests of other users. A user can also use the extension to request the revocation of a role or, if the user has the appropriate rights, to revoke roles for other users. All of these requests are handled as FIM workflows, allowing administrators to ensure that the requests are subject to FIM workflow management.

Some configuration required to administer BHOLD FIM Integration requires you to use the BHOLD Core portal. In order to use the BHOLD Core portal to administer BHOLD Core, you must be logged on with the root account (by default, the account that was used to install BHOLD Core), or an account with the same BHOLD and SQL Server permissions as the root account. Start the BHOLD Core portal by typing the following URL in the address bar of a web browser: https://<portal_server>:5151/BHOLD/Core, where <portal_server> is the IP address or server name of the server running BHOLD Core.

Other administrative tasks for BHOLD FIM Integration are performed using the FIM Portal. To user the FIM Portal to administer BHOLD FIM Integration, you must be logged on with an account that has permissions required to administer FIM and BHOLD Core. Start the FIM Portal by typing the following URL in the address bar of a web browser: https://<FIM_server>/IdentityManagement, where <FIM_server> is the IP address or server name of the server running FIM.

This section covers the following topics:

• Understanding role-based access control and BHOLD

• Understanding the role-approval process in BHOLD FIM Integration

• Managing role approval on a continuing basis

Understanding role-based access control and BHOLD

Role-based access control is a mechanism for classifying users according to their various roles within an organization and then controlling their access to data and applications based on those roles. These roles can be assigned to users manually, but role assignment can also be performed automatically, based on changes to the users’ status within the organization itself. For example, by assigning to a user attributes that specify the user’s job title and project assignments, the user can be granted access to tools needed for the user’s job and to data that the user needs to contribute to a particular project. When the user assumes a different job and different project assignments, changing the user’s job title and projects automatically blocks access to the resources that were required only for the user’s previous position and provide access to the resources the user needs for the new position.

Another way to reflect a user’s status or function within the organization is by linking the user to an organizational unit (orgunit). Orgunits can be arranged hierarchically to mirror the structure of the organization itself, or they can be created and arranged to represent the structure of a project, security classification system, or any other hierarchical arrangement. A role can be linked unconditionally to an orgunit, so that all users in the orgunit are automatically assigned the role, and the role can be inherited by lower-level orgunits in the structure. A role can also be linked provisionally to an orgunit subject to time limits, and a role can be linked to an orgunit as a proposed role that must be activated for a user before it becomes effective. The principal purpose of the BHOLD FIM Integration extensions to the FIM Portal is to make the activation and deactivation of proposed roles easily accessible to users who are not BHOLD administrators.

For more information about RBAC and BHOLD, see Introduction to administering Microsoft BHOLD Core in Microsoft BHOLD Core Operations Guide.

Understanding the role-approval process in BHOLD FIM Integration

The BHOLD FIM Integration extensions to the Forefront Identity Manager 2010 R2 (FIM) Portal are used to approve the activation of proposed roles for users. Only specifically authorized users can approve role activation. When a request to activate a role is submitted, a FIM workflow is triggered that routes the request to the appropriate approver or approvers. The workflow can route the request to multiple approvers, and if any user denies the request, the workflow is stopped.

There are three categories of users who have the authority to approve roles:

• Role managers are users who have the responsibility of approving the activation of proposed roles, regardless of the organizational unit (orgunit) that they are linked to.

• Line managers are users who have the responsibility of approving the proposed roles that are linked to a particular orgunit

• Security officers are users who have general responsibility for approving proposed roles

The BHOLD FIM Integration module provides two mechanisms for giving these users responsibility for approving proposed roles for an organization:

• By linking the user to a role-approval role. A role-approval role is a BHOLD role that has the Role Type attribute set to Approver, Escalator, or Security Officer. These terms are explained later in this section. For more information about creating and applying a role-approval role, see Understanding role-approval roles later in this topic.

• By setting predefined attributes for a role or orgunit. The attributes specify the type of responsibility that the user has as a role manager overseeing a role or as a line manager overseeing an orgunit. By default, the Role and Orgunit object types in BHOLD Core do not include the attribute types required to make role-approval assignments. You must first add them to the object type before you can use them to specify the users who have responsibility for the role-approval process. For information about creating and setting these attributes, see Understanding object attributes for role approvers later in this topic.

These methods (role-based and attribute-based) can be used exclusively or in combination. If they are combined, BHOLD FIM Integration follows this order of precedence:

• If a role-approval role with the Role Type set to Approver is linked to the proposed role (either as a subrole or through an orgunit), an approval workflow is started with the designated approver. Note that even when the role-approval role is linked directly to the proposed role, the approval applies specifically to the proposed role of a particular orgunit.

• If there is no approver role, BHOLD FIM Integration checks the attributes of the orgunit and proposed role for an approver. If an approver is found for the orgunit or for the proposed role, BHOLD FIM Integration begins the approval workflow with the designated approver.

• If there is no approver for the proposed role or for the orgunit, BHOLD FIM integration checks the attributes of the parent orgunit, continuing up the hierarchy until an orgunit approver is found. The approval workflow then begins with the designated orgunit approver.

• If no approver is found in the orgunit hierarchy, then BHOLD FIM Integration approves the proposed role activation automatically.

Users can be assigned the following functions in the role approval process:

• Primary approver, the user who receives the initial request for approval. This function can be assigned by linking the user to a role-approval role with the Role Type set to Approver, or by specifying the user in an approver attribute in the proposed role or orgunit.

• Escalation approver, the user who receives the request for approval if a primary approver (line or role manager) doesn’t respond after a set number of days. This function can be assigned by linking the user to a role-approval role with the Role Type set to Escalator, or by specifying the user in an escalator attribute in the proposed role or orgunit.

  The default number of days that must elapse before the request is forwarded to the escalator is seven, but this number can be changed. For more information, see Managing BHOLD workflows in the FIM Portal in this guide.

• Security officer, a user who is responsible for organizational security and who is required to approve activation in addition to approvals by role or line managers. This function can be assigned by linking the user to a role-approval role with the Role Type set to Security Officer, or by specifying the user in a securityOfficer attribute in the proposed role or orgunit. If approval by a security officer is required to approve the activation of a proposed role, the role is not activated until a security officer approves the activation. There is no escalation processes for security officers.

More than one user can be designated as a primary approver, an escalation approver, or a security officer. In this case, approval requests are routed to all users that are designated for a particular approval function. If the first response of any user with a particular approval function denies the request, the approval workflow is immediately stopped and the request for activation is rejected. Otherwise, any one of them can approve the activation of the proposed role and the approval workflow then continues with the next step, and any additional actions by users in the same set are ignored.

BHOLD FIM Integration provides the required FIM components and settings to execute the following workflows:

• No approval required for a role-activation request

• Approval by a line manager is required

• Approval by a role manager is required

• Approval by a line manager and a role manager is required

• Approval by a security officer is required

• Approval by a line manager and a security officer is required

• Approval by a role manager and a security officer is required

• Approval by a line manager, a role manager, and a security manager is required

As noted previously, a line manager or a role manager can be either a primary approver or an escalation approver if no action is taken by a primary approver after a preset period. Activation requests to security officers are not escalated.

If approval by more than one set of approvers (line managers, role managers, or security officers) is required, the approval requests are submitted simultaneously (that is, in parallel). Final approval or denial does not occur until one user in each set has responded to the request.

Approval is not required if there are no primary approvers (line or role manager), escalation approvers (line or role manager), or security officers linked to the proposed role or orgunit.

This diagram illustrates the approval workflow process:

Understanding role-approval roles

Role-approval roles allow you to centrally manage which users are authorized to approve proposed role activation requests. You can use role-approval roles to establish role managers for proposed roles, and you can use role-approval roles to designate line managers for organizational units (orgunits).

Specifying role managers for a proposed role by using a role-approval role consists of four steps:

1. Create a role and set its Role Type attribute to Approver, Escalator, or Security Officer.

2. Link the appropriate role managers to the role-approval role.

3. Link the role-approval role to the proposed role as a subrole.

4. Link the proposed role to one or more orgunits.

When this method is used, the users linked to the role-approval role are permitted to approve the activation of the proposed role regardless of which orgunit it is linked to.

This diagram shows the relationship between objects in a role-based role-manager relationship:

In this diagram, User1 is linked to a role that has its roletype attribute set to Approver and that is linked as a subrole to a proposed role that is linked to an orgunit. When a request is submitted to activate the proposed role for a user in an orgunit, the request is routed to User1 for approval.

Using role-approver roles to specify line-manager role approvers for an orgunit is similar, but the role-approval role is linked directly to orgunits:

1. Create a role and set its Role Type attribute to Approver, Escalator, or Security Officer.

2. Link the appropriate role managers to the role-approval role.

3. Link the role-approval role to the orgunits that you want the role managers to oversee.

When this method is used, the users linked to the role-approval role are permitted to approve the activation of any proposed role linked to the orgunit.

This diagram shows the relationship between objects in a role-based line-manager relationship:

In this diagram, User1 is linked to a role that has its roletype attribute set to Approver and that is directly linked to the orgunit that the proposed role is linked to. When a request is submitted to activate a proposed role for a user in the orgunit, the request is routed to User1 for approval.

For information about creating and using role-approval roles, see Managing approval for proposed roles with role-approver roles and Managing approval for BHOLD organizational units with role-approver roles elsewhere in this guide.

Understanding object attributes for role approvers

While using role-approval roles to assign role approvers makes it easy to centrally manage the role-approval process, using organizational-unit (orgunit) or proposed-role attributes to assign approval responsibilities to users allows you to maintain fine-grained control over the approval process without creating an unwieldy number of role-approval roles.

To use attributes to manage role approval for the proposed roles linked to an orgunit, you must add predefined attributes to the orgunit object data type in BHOLD and then use those attributes to specify the approvers for each orgunit or hierarchical branch of orgunits. Similarly, to use attributes to manage role approval for proposed roles regardless of the orgunit that they are linked to, you must add predefined attributes to the role object data type and then use those attributes to specify the approvers for each proposed role. In both cases, you add one or more of the following attributes to the orgunit or role data type:

• approver*<n>*

• escalator*<n>*

• securityOfficer*<n>*

where <n> represents an optional number you can use to specify more than one approver of each type. For a description of these approver types, see Understanding the role-approval process in BHOLD FIM Integration earlier in this topic.

Specifying role managers to approve role activation for a proposed role by using attributes consists of two steps:

• Add one or more attributes to the BHOLD role data type.

• Set the attributes in the proposed role to specify users for each approval function.

When this method is used, the users specified in the attributes of the role-approval role are permitted to approve the activation of the proposed role regardless of which orgunit it is linked to.

This diagram shows the relationship between objects in an attribute-based role-manager relationship:

In this diagram, User1 is specified in the approver1 attribute of the proposed role. User1 is not actually linked to the role, and need not be a member of (that is, linked to) the orgunit that the proposed role is linked to. When a request is submitted to activate the proposed role for a user in an orgunit, the request is routed to User1 for approval.

Using attributes to specify line-manager role approvers for an orgunit is similar, but the role-approval attributes are specified for each orgunit or hierarchical branch of orgunits, not for the proposed role:

• Add one or more attributes to the BHOLD orgunit data type.

• Set the attributes in the orgunit to specify users for each approval function.

  Note

  Attributes set on an orgunit also apply to its child orgunits unless overridden by attributes on a child orgunit.

When this method is used, the users specified in the orgunit attributes are permitted to approve the activation of any proposed role that is linked to the orgunit.

This diagram shows the relationship between objects in an attribute-based line-manager relationship:

In this diagram, User1 is specified in the approver1 attribute of the orgunit. User1 need not be a member of (that is, linked to) the orgunit itself. When a request is submitted to activate a proposed role for a user in the orgunit, the request is routed to User1 for approval.

For information about using attributes to specify role approvers for roles and orgunits, see Managing approval for proposed roles with attributes and Managing approval for BHOLD organizational units with attributes elsewhere in this guide.

Managing role approval on a continuing basis

Generally speaking, once you have implemented your BHOLD FIM Integration approval framework, there is little additional maintenance required, other than keeping it up-to-date with changes in your organization. For example, if a user who is designated as a line-manager approver moves to a different part of your organization, you should replace that user as a line manager for the organizational units (orgunits) that the user previously supervised. When users who are designated approvers leave the organization, it is critical that you replace those approvers with active users as soon as possible; otherwise, the role-activation approval process can be unnecessarily delayed or even blocked. For that reason, you should ensure that you design your role approval framework with enough redundancy to ensure that the failure of one approver to respond to a request will not stall the approval process.

You should periodically review the appropriateness of role-approver assignments, and you should have procedures in place to respond to structural changes in your organization that are reflected in your orgunit and role structure. It is important to remember that when no approvers are designated for a proposed role, requests for activation of that role are automatically granted.

See also

• Microsoft BHOLD FIM Integration Operations Guide

  • Administering Microsoft BHOLD FIM Integration