BHOLD Core technical reference

 

Updated: July 28, 2013

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:

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.

BHOLD RBAC job functions

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.

Supervisor roles and permissions

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.

Supervisor roles

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.

BHOLD permissions

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

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

TaskBHOLD PermissionsSupervision
Create applicationApplication Create

Application Modify Attributes

Application Owner
The supervisor role that is to be linked to the application
Modify application attributesApplication Modify AttributesThe application
Remove applicationApplication RemoveThe application
Create permissionsApplication Permission Create

Permission Modify Attributes

Permission Owner
The application

The supervisor role that is to be linked to the permission
Remove permissionsApplication Permission RemoveThe application

The permission
Link or unlink supervisor rolesApplication OwnerThe application

The supervisor role(s) that are to be linked to or unlinked from the application
Manage application queueSysInfoThe application

Permission responsibilities

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

TaskBHOLD PermissionsSupervision
Create permissionsApplication Permission Create

Permission Modify Attributes

Permission Owner
The application

The supervisor role that is to be linked to the permission
Modify permission attributesPermission Modify AttributesThe permission

The application that the permission is defined under
Remove permissionsApplication Permission RemoveThe application

The permission
Link or unlink supervisor rolesPermission OwnerThe permission

The application that the permission is defined under

The supervisor role(s) that are to be linked to or unlinked from the permission
Define incompatible permissionsPermission Incompatible PermissionsThe permissions that are to become incompatible

The application(s) that the permissions are defined under

Role responsibilities

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

TaskBHOLD PermissionsSupervision
Create roleRole Create

Role Modify Attributes

Role Owner
The supervisor role that is to be linked to the role
Modify role attributesRole Modify AttributesThe role
Remove roleRole RemoveThe role
Link or unlink parent or sub-rolesRole ParentSubRoleThe role

The roles that are to be set or removed as parent or sub-roles
Link or unlink permissionsRole PermissionsThe role

The Permissions that are to be linked to or unlinked from the role
Link or unlink supervisor rolesRole OwnerThe role

The supervisor role(s) that are to be linked to or unlinked from the role
Define Attribute Based Authorization rulesRole ABA

Maintain Attributes
The role

Organizational unit responsibilities

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

TaskBHOLD PermissionsSupervision
Create orgunitOrgunit Children Create

OrgUnit Modify Attributes

OrgUnit Owner
The orgunit that the new orgunit is to be created under
Modify orgunit attributesOrgUnit Modify AttributesThe orgunit
Move orgunitOrgUnit Modify Attributes

OrgUnit Move

OrgUnit Owner
The orgunit

The orgunit that the orgunit is moved from

The orgunit that the orgunit is moved to
Remove orgunitOrgUnit Children RemoveThe parent orgunit of the orgunit that is to be removed
Create userOrgUnit User CreateThe orgunit that the new user is to be created under
Move userOrgUnit UsersThe orgunit that the user is moved from

The orgunit that the user is moved to
Remove userOrgUnit User RemoveThe orgunit that contains the user
Link usersOrgUnit UsersThe orgunit

The orgunit(s) that contain the user(s) that are to be linked
Unlink usersOrgUnit UsersThe orgunit
Link or unlink effective rolesOrgUnit RolesThe orgunit

The roles that are to be linked to or unlinked from the orgunit
Link or unlink proposed rolesOrgUnit PropRolesThe orgunit

The roles that are to be linked to or unlinked from the orgunit
Activate or revoke inherited effective rolesOrgUnit InherRoles ActRevThe orgunit

The inherited roles that are to be activated or revoked
or
OrgUnit InhRoles ActRev Extended ViewThe orgunit
Activate or revoke directly linked proposed rolesOrgUnit PropRoles ActRevThe orgunit

The proposed roles that are to be activated or revoked
Activate or revoke inherited proposed rolesOrgUnit PropRoles ActRevThe orgunit

The inherited proposed roles that are to be activated or revoked
or
OrgUnit PropRoles ActRev Extended ViewThe orgunit
Link or unlink supervisor rolesOrgUnit OwnerThe orgunit

The supervisor role(s) that are to be linked to or unlinked from the orgunit

User responsibilities

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

TaskBHOLD PermissionsSupervision
Create userOrgUnit User CreateThe orgunit that the new user is to be created under
Modify user attributesUser Modify AttributesThe orgunit that contains the user
Reset user passwordUser password ResetThe orgunit that contains the user
or
User password Reset All

View All
None required: enables password reset on all users
Move userOrgUnit UsersThe orgunit that the user is moved from

The orgunit that the user is moved to
Remove userOrgUnit User RemoveThe orgunit that contains the user
Link or unlink rolesUser RolesThe orgunit that contains the user

The roles that are to be linked to or unlinked from the user
Activate or revoke inherited effective rolesUser InhRoles AcRevThe orgunit that contains the user

The inherited roles that are to be activated or revoked
Activate or revoke inherited proposed rolesUser PropRoles AcRevThe orgunit that contains the user

The inherited proposed roles that are to be activated or revoked

Auditor responsibilities

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

TaskBHOLD PermissionsSupervision
Create auditorApplication OwnerThe application for which the auditor is to be created
Modify auditor-The application for which the auditor is to be modified
View auditor reportsView AllNone required
Remove auditorApplication OwnerThe application for which the auditor is to be removed

Other responsibilities

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

TaskBHOLD PermissionsSupervision
Manage attribute typesMaintain AttributesNone required
Manage attribute type setsMaintain AttributesNone required
Manage data typesMaintain AttributesNone required
Manage message translationsMaintain AttributesNone required
Manage object typesMaintain AttributesNone required
Manage orgunit typesMaintain OrgUnit TypesNone required
Manage system parametersSysInfoNone required
Queue background processesSysInfoNone required
Manage B1QueueSysInfoNone required

Independent permissions

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.

BHOLD PermissionTasks
Do AllUsers who have this permission can perform all tasks on all objects. Having this permission is thus equivalent to having all other permissions and being supervisor of all the objects in BHOLD.
Maintain AttributesUsers who have this permission can perform the following tasks:

- Manage attribute types
- Manage attribute type sets
- Manage data types
- Manage message translations
- Manage object types
SysInfoUsers who have this permission can perform the following tasks:

- Manage system parameters
- Queue background processes
- Manage B1Queue
View AllUsers who have this permission can perform the following tasks:

- View all applications
- View all permissions
- View all roles
- View all orgunits
- View all users
- View all auditors
- View auditor reports

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

NameDescriptionDefault Value
B1EnforceABARepeatIntervalThe number of days between attribute-based authorization (ABA) runs01
B1EnforceABAStarthourThe hour (using a 24-hour time notation) when each ABA run will occur. For example, 23 for 11:00 p.m.01
bholdAuthenticationThe authentication method for the BHOLD website. The following values are acceptable:

- Basic
- Certificates
- WindowsCertificates
- WindowsPasswords
WindowsPasswords
bholdDirectoryLocation of the BHOLD softwareSpecified during installation.
bholdDomainDomain name for the user accountsDomain or server name specified during installation
bholdGroupThe security group of which the BHOLD Core service account is a member. This account is used for access to the BHOLD database (B1)Specified during installation
BHOLDSiteThe location of the BHOLD web site/BHOLD/bhold.aspx
BHOLDUserName of the BHOLD Core service accountSpecified during installation
NoDBVersionCheckDisables checking the version of the databaseN
ReportsEnables the Reports menu itemN
ScriptserverDomain of the serverSpecified during installation
ScriptServiceThe service for scriptingBHOLD
ServiceIntervalThe interval (in seconds) between runs of the b1service service10
SMTPMailFromThe email address of the BHOLD representativeSpecified during installation
SMTPServerThe server address of the SMTP (email) serverSpecified during installation
SQLDatabaseThe name of the SQL Server databaseSpecified during installation
SQLServerThe name of the SQL ServerSpecified during installation
SQLConnectionStringThe ODBC connection stringNot present by default. This is used only during setup when using SQL security. This value is encrypted after the b1service has started during installation
SQLConnectionStringEncryptedThe encrypted ODBC connection stringNot present by default. This is used only when using SQL security. This value is the encrypted version of SQLConnectionString.
UnAssignedTaskIntervalThe expiration time (in seconds) of activated application permissions of users5
webDirectoryThe directory where the BHOLD web site is locatedThe location specified in BHOLDDirectory concatenated with \web
webNameThe name of the virtual directory in Microsoft Internet Information Services (IIS)BHOLD
webServerThe application server that publishes the BHOLD web siteThe name of the server on which BHOLD is installed
WebVDIRWhether IIS uses a virtual directory for the BHOLD web siteY

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

NameDescriptionDefault Value
XSLdirectoryLocation of the Styles directorySpecified during installation

BHOLD Core uses the following virtual web directories:

Web nameLocationRemarks
BHOLD<BHOLD Root>\WebThe normal website
(optional)Styles<BHOLD Root>\web\StylesLocation for XSL style sheets

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

AttributeSettings
NameBHOLD
Path<BHOLD Root>\Web
AccessSSLTrue
AuthAnonymousFalse
AuthBasicTrue

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

AttributeSettings
NameBHOLD
Path<BHOLD Root>\Web
AccessSSLTrue
AccessSSL128False
AccessSSLNegotiateCertTrue
AccessSSLRequireCertTrue
AccessSSLMapCertFalse
AuthAnonymousTrue

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

AttributeSettings
NameBHOLD
Path<BHOLD Root>\Web
AccessSSLTrue
AccessSSL128False
AccessSSLNegotiateCertTrue
AccessSSLRequireCertTrue
AccessSSLMapCertTrue
AuthAnonymousTrue

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

AttributeSettings
NameBHOLD
Path<BHOLD Root>\Web
AccessSSLFalse
AuthAnonymousFalse
AuthNTLMTrue

The Styles website has the following settings:

AttributeSettings
NameStyles
Path<BHOLD Root>\Web\styles
AuthAnonymousTrue

The BHOLD Core website has two entry points:

Page nameFunction
BHOLD.aspxEntry point to the user-interface
B1ScriptService.asmxEntry point to the scripting functions
Show: