Introduction to administering Microsoft BHOLD Core
Applies To: Forefront Identity Manager
Microsoft® BHOLD Suite Service Pack 1 (SP1) is a companion to Microsoft Forefront Identity Manager (FIM) 2010 that adds role-based access control (RBAC) to the identity lifecycle management provided by FIM. RBAC gives organizations the ability to define user roles and to control user access to sensitive data and applications according to those roles. BHOLD Suite consists of a set of modules that provide a wide range of tools and services to integrate RBAC with FIM, to create and maintain a role model that instantiates the RBAC policies of your organization, and to ensure that RBAC policies are being suitably applied and verified.
This section covers the following topics:
An overview of RBAC
How BHOLD helps implement RBAC
Using the BHOLD Core portal
An overview of RBAC
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.
Roles can contain other roles in a hierarchical or parent/child manner, enabling inheritance of permissions from higher-level roles to roles lower in the hierarchy. For example, in a hospital, all medical personnel could be given the right to view a patient’s records, but only physicians (a subrole of the medical role) could be given the right to order prescriptions for the patient. Similarly, users belonging to the clerical role could be denied access to patient records except for billing clerks (a subrole of the clerical role), who could be granted access to those portions of a patient’s records that are required to bill the patient for services provided by the hospital. This principle of inheritance reduces the number of roles that need to be assigned to a user. That is, instead of having to assign both the clerical role and the medical role and the physician role to a user, assigning only the physician role is necessary because it can inherit all the permissions associated with the medical role.
RBAC also provides a structured method for defining and enforcing separation of duties (SoD). By enforcing SoD, you can ensure that no user can be assigned roles that grant permissions that shouldn’t be granted to a single person. For example, RBAC-based enforcement of SoD could prevent a single user from being assigned roles that would enable the user both to initiate and to authorize a payment, violating company policies designed to prevent fraud.
How BHOLD helps implement RBAC
The Microsoft BHOLD Suite does not replace the access control mechanisms of the operating systems and applications that an organization uses. Instead, it provides a framework which an organization can use to model the principles of RBAC so they can be applied to and enforced by the access control mechanisms that are already in place.
An example is how BHOLD Suite works with Forefront Identity Manager (FIM) and Active Directory Domain Services (AD DS) to apply role-based access control by using the discretionary access control (DAC) mechanisms of Active Directory and the Windows file system. Typically access to files and folders in the Windows file system is controlled by using access control lists (ACLs) that determine how specific users or groups of users can access a particular file or folder. However, whether a user belongs to a particular group is typically arbitrary, because group membership is usually maintained manually or through workflow mechanisms that control membership by means of an approval process. BHOLD Suite, on the other hand, allows an organization to create and apply a model that automatically controls group membership according to RBAC principles.
The first step in BHOLD Suite is to create an application in the BHOLD Core database; the application is simply an object in the database that will be associated with permissions that can be assigned to specific roles. In the case of the example of AD DS, the application would be Active Directory itself. Next, a mechanism is created to associate BHOLD permissions with the access-control mechanism of the application. In the case of Active Directory, FIM management agents (MAs) are created that import permissions from BHOLD into FIM and then export them to Active Directory to create corresponding security groups in Active Directory. MAs are also used to synchronize the permission assignments with the security groups by adding or removing users in the security groups when BHOLD assigns or removes permissions from individual users. (Note that these MAs are created after the BHOLD Access Management Connector module has been installed and before BHOLD Suite is put into production.) The resulting security groups are then used to control access to files and folders in Windows.
It’s important to remember that individual users are not directly assigned permissions in BHOLD. Instead, the purpose of RBAC in general and BHOLD in particular is to ensure that users receive only those permissions that are appropriate for their roles in the organization. As suggested earlier, these roles can be based on the user’s place in the organization (such as the user’s manager), the user’s participation in a cross-organizational project (such as a task force), the user’s function (such as job title), or any other policy-based criteria (such as security-clearance level). When a user is assigned a role in BHOLD, the permissions that are associated with that role are assigned to the user as well, and these permissions are then synchronized to Active Directory as memberships in the security groups that are associated with those permissions.
Active Directory is but one example of an application which can be brought into an RBAC-based security infrastructure that is managed by BHOLD. Essentially, BHOLD provides the mechanism to associate users with roles and roles with permissions. It is the applications’ responsibility to enforce those permissions by whatever mechanism is provided within that application.
Using the BHOLD Core portal
The BHOLD Core portal gives you the ability to manage the role model that BHOLD Core maintains on behalf of your organization. The role model consists of the following object types:
Users—objects that represent individual persons within the role model
Organizational units—objects that represent groups of users or other organizational units (orgunits)
Roles—objects that represent a classification of one or more users for which permissions can be applied
Permissions—objects that represent the ability to perform an action through an application
Applications—objects that represent an external system that enforces permissions
Accounts—objects that represent the identity of individuals within applications
In a well-designed, normalized role model, each person in the organization is represented by a single user object. This user object, in turn, will be associated with one or more accounts (depending on the number of applications involved) and will belong to one or more organizational units. Each user object will also be associated with one or more roles, and each role will be associated with one or more permissions. Note that the permissions associated with a particular role need not be enforced by a single application. A role assigned to group managers, for example, could provide permissions that give access to a human resources portal, a purchasing application, and a time-tracking system.
The BHOLD Core portal also gives you the ability to extend the default role model schema provided by BHOLD. By using the portal, you can add object types, organizational unit types, attribute types and attribute type sets, and data types to the role model schema. This allows you to extend the schema to meet your changing requirements, as when you add an application to BHOLD whose data representations don’t easily fit in the default BHOLD schema.
Because BHOLD is designed to work closely with Forefront Identity Manager (FIM), most BHOLD deployments will rely on the ability of FIM to manage user identities across multiple platforms. In practice, that means that users, accounts, and organizational structures in the BHOLD role model will be provisioned from an external source, such as a human relations database or perhaps Active Directory. In turn, many roles and permissions can be created automatically by BHOLD Core based on organizational structures and specified user attributes, such as job title or rank. Consequently, you will rarely use the BHOLD Core portal to add users and accounts to the role model, for example, and any organizational units, roles, and permissions you create will typically be for such special purposes as organizing a project team or providing special access that is not based on the usual organizational criteria.
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.
Tip
The BHOLD Core portal lets you locate many items in the BHOLD Core database by search for strings. You can use the asterisk (*) wildcard character to match any number of characters in a search string if you want to match multiple items. For example, the search string PR-* matches all personal roles created by BHOLD Core, and the search string PR-*Temp* matches all personal roles for users with Temp as part of the user descriptions.