BHOLD Core technical reference

Applies To: Forefront Identity Manager

This section contains information that will help you better understand and manage the BHOLD Core module of Microsoft® BHOLD Suite Service Pack 1 (SP1). It covers the following topics:

• Inward Access Control

• BHOLD Core permissions

• BHOLD Core registry settings

• BHOLD Core web site settings and entry points

By using Microsoft BHOLD core to implement a role-based access control (RBAC) system, you can control user access to information and applications based on a user’s function within an organization. Within the RBAC system, a role model is designed that delineates roles that are mapped to a job function. Access permissions that are required to perform those roles are associated with those roles, and then the permissions are granted to each user by assigning the associated roles to the user based on the user’s job function. This simplifies the task of assigning permissions to multiple users with the same or similar job functions and ensures that permissions are assigned to users specifically to satisfy the requirements of those job functions.

Most often, then, RBAC is deployed within an organization in order to enable users to perform tasks that meet the organization’s business requirements. In order to be effective, however, an RBAC system must also implement role-based inward access control, that is, to control access to the RBAC system itself based on users’ job functions relative to the RBAC system. In other words, the access required to view and manage the RBAC role model must be role-based as well.

Requiring role-based access to the RBAC system itself enables the enforcement of separation of duties (SoD) policies that prevent the compromising of the integrity of the RBAC system. It also allows the implementation of governance for internal policies as well as external legal and regulatory constraints. In this way, responsibility for implementation and enforcement of policy can be separated from day-to-day control of the RBAC system.

Implementing inward access control of the BHOLD role model requires the identification of two types of job functions that involve access to the BHOLD: organizational job functions and model-management job functions.

Organizational job functions relate to the activities of the organization itself, and can include the following:

• Unit managers are responsible for managing the work of a particular group (such as a group or department) of users. These managers focus on ensuring that the users under their supervision have the resources needed to perform their respective tasks, and so are often given the ability to access the BHOLD role model to assign roles to the users they are responsible for. Depending on the manager’s level in the organization, these users will be grouped in the role model in one or more organizational units (orgunits) or orgunit branches.

• Project managers have the responsibility of managing the work of one or more teams that cross organizational boundaries in order to accomplish a particular task. In addition to being grouped into orgunits that represent the hierarchy of the organization, these teams will also be grouped into orgunits that correspond to the hierarchical relationships within the project team. As with unit managers, project managers are often responsible for assigning roles to the users who are members of the project team.

Model-management job functions are tasked with managing the BHOLD role model. Rather than being concerned with individual users, they focus on the design and integrity of the role model itself. These job functions can be separated into various specialties, such as the following:

• Application managers are responsible for analyzing the permissions that should be required to use the organization’s applications and the users’ job functions that require those permissions.

• Organization managers design the orgunit structure of the role model and the proper placement of users within that structure.

• Role-model managers are tasked with the day-to-day control of the role model in BHOLD Core, such as linking roles to permissions and to orgunits.

• Auditors have the responsibility of verifying that the role model design and implementation conform to the organization’s internal policies and external (legal and regulatory) requirements. Typically, auditors are given read-only access to the role-model database and consequently depend on other types of model managers to correct deficiencies that the auditors uncover.

• Help desk technicians respond to requests for assistance from end users and usually are restricted to identifying issues and escalating them to other model managers for correction.

• User managers work with human resources departments and others to add and remove users in the role model and to link them to appropriate orgunits.

Depending on the size of the organization, some of these functions can be performed by the same person, such as the role-model and user management functions.

To maintain proper separation of duties among these job functions, you must create corresponding roles in BHOLD and use them to assign permissions and supervisorship to the users holding those job functions. Supervisor roles and permissions provides an overview of how to do this.

Inward access control of the BHOLD model requires the assignment of two types of inward-facing access controls. BHOLD Core permissions control the types of changes that a user can make to the BHOLD role model, while supervisor roles determine what parts of the BHOLD role model a user can view. Of course, a user must have the necessary supervisor role to view the role-model parts that the user needs to change, so a user tasked with maintaining all or part of the BHOLD role model must be assigned both supervisor roles and BHOLD Core permissions for the appropriate parts of the role model. On the other hand, a user whose responsibilities are to monitor or audit the role models only needs the necessary supervisor roles. Because supervisor roles are essential to both monitoring and managing the BHOLD role model, they will be discussed first.

The structure of supervisor roles in BHOLD, sometimes referred to as ownership structure, determines which users can access (but not change) specific objects. Orgunits, roles, permissions, and applications must be linked to at least one supervisor role. For this reason, BHOLD provides a default supervisor role to which it automatically links to these objects when they are created. It is a best practice to maintain the link between these role-model objects and the default supervisor role to ensure that the object can be properly managed if other supervisors are unable to do so. In addition to the default supervisor role, these role-model objects should be linked to at least one other supervisor role to provide proper separation of duties for managing the object.

A supervisor role is a special class of role within the BHOLD role model. When you create the supervisor role, you designate it as a supervisor role. Unlike other roles, however, you should not link permissions to the supervisor role. Instead, you link the supervisor role to the users who are responsible for a particular object in the role model (such as an orgunit or role) and then link it to that object as a supervisor role. This gives the users who are linked to the supervisor role access to the object that the supervisor role is linked to. Note, however, that unless they have the necessary permissions to modify the object, they can only view the object, not change it.

It’s important to remember that a supervisor role should be linked to itself as a supervisor role. This enables the users that are linked to the supervisor role to link objects to the supervisor role.

By assigning BHOLD Core permissions to a user, you grant the user the ability to changes in specific types of objects of the BHOLD role model. For a complete listing of these permissions and their corresponding purposes, see BHOLD Core permissions later in this topic.

As noted previously, it is not considered a best practice to link BHOLD permissions directly to supervisor roles. Instead, to give a user the ability to manage part of the BHOLD role model, you should create a separate, nonsupervisory role, link the permissions to that role, and then link that role and the appropriate supervisor role to the user. This allows you to link the supervisor role to users who should not be given the ability to change the role-model object.

As noted earlier in this topic, a user who is tasked with managing objects in the BHOLD role model must be linked to a supervisor role for that object. This only gives the user the ability to view the object in the role-model, however. In order to change certain objects (such as by adding a user to an orgunit, or to change the supervisor roles for the object), the user must also be linked to an owner permission for the object. The objects that require owner permissions are the orgunit, permission, role, and application objects. For more information about when these owner permissions are required, see BHOLD Core permissions later in this topic.

Most BHOLD Core permissions pertain to specific object types. However, there are six system permissions that provide broad access to BHOLD Core:

• BHOLD Do All allows a linked user to perform all actions in BHOLD Core.

• BHOLD View All gives a linked user the ability to view every object in the BHOLD role model.

• BHOLD Full User Interface permits a linked user to access the entire BHOLD Core portal.

• BHOLD Maintain Attributes allows a linked user to create and maintain attribute types on role-model objects.

• BHOLD Maintain Orgunit Types gives a linked user the ability to create and maintain different types of orgunits.

• BHOLD Sysinfo permits a linked user to work with background processes in BHOLD Core.

In order to fulfill management responsibilities in BHOLD, you need to have a combination of BHOLD permissions and supervisor rights. These permissions and rights are listed in the following tables:

• Application responsibilities

• Permission responsibilities

• Role responsibilities

• Organizational unit responsibilities

• User responsibilities

• Auditor responsibilities

• Other responsibilities

• Independent permissions

The following table shows the BHOLD permissions and supervision that are required for managing applications.

The following table below shows the BHOLD permissions and supervision that are required for managing permissions.

The following table shows the BHOLD permissions and supervision that are required for managing roles.

The following table the BHOLD permissions and supervision that are required to manage organizational units (orgunits).

The following table shows the BHOLD permissions and supervision that are required manage users.

The following table shows the BHOLD permissions and supervision that are required to manage auditors.

The following table shows the BHOLD permissions that are required for other management tasks.

A few BHOLD permissions enable users to perform certain tasks without needing other permissions or supervisor rights. The following table shows those permissions and the tasks they enable.

The following tables list BHOLD Core registry entries according to location. Each table provides a description and default value for the registry entries.

Location in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\bhold\b1Core

Location in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\bhold\common

BHOLD Core uses the following virtual web directories:

The BHOLD Core website has the following settings when the registry entry BHOLDAuthentication is set to Basic:

The BHOLD Core website has the following settings when the registry entry BHOLDAuthentication is set to Certificates:

The BHOLD Core website has the following settings when the registry entry BHOLDAuthentication is set to WindowsCertificates:

The BHOLD Core website has the following settings when the registry entry BHOLDAuthentication is set to WindowsPasswords:

The Styles website has the following settings:

The BHOLD Core website has two entry points: