Export (0) Print
Expand All

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:

Inward Access Control

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.

BHOLD Core permissions

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.

 

Task BHOLD Permissions Supervision

Create application

Application Create

Application Modify Attributes

Application Owner

The supervisor role that is to be linked to the application

Modify application attributes

Application Modify Attributes

The application

Remove application

Application Remove

The application

Create permissions

Application Permission Create

Permission Modify Attributes

Permission Owner

The application

The supervisor role that is to be linked to the permission

Remove permissions

Application Permission Remove

The application

The permission

Link or unlink supervisor roles

Application Owner

The application

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

Manage application queue

SysInfo

The application

Permission responsibilities

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

 

Task BHOLD Permissions Supervision

Create permissions

Application Permission Create

Permission Modify Attributes

Permission Owner

The application

The supervisor role that is to be linked to the permission

Modify permission attributes

Permission Modify Attributes

The permission

The application that the permission is defined under

Remove permissions

Application Permission Remove

The application

The permission

Link or unlink supervisor roles

Permission Owner

The 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 permissions

Permission Incompatible Permissions

The 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.

 

Task BHOLD Permissions Supervision

Create role

Role Create

Role Modify Attributes

Role Owner

The supervisor role that is to be linked to the role

Modify role attributes

Role Modify Attributes

The role

Remove role

Role Remove

The role

Link or unlink parent or sub-roles

Role ParentSubRole

The role

The roles that are to be set or removed as parent or sub-roles

Link or unlink permissions

Role Permissions

The role

The Permissions that are to be linked to or unlinked from the role

Link or unlink supervisor roles

Role Owner

The role

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

Define Attribute Based Authorization rules

Role ABA

Maintain Attributes

The role

Organizational unit responsibilities

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

 

Task BHOLD Permissions Supervision

Create orgunit

Orgunit Children Create

OrgUnit Modify Attributes

OrgUnit Owner

The orgunit that the new orgunit is to be created under

Modify orgunit attributes

OrgUnit Modify Attributes

The orgunit

Move orgunit

OrgUnit 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 orgunit

OrgUnit Children Remove

The parent orgunit of the orgunit that is to be removed

Create user

OrgUnit User Create

The orgunit that the new user is to be created under

Move user

OrgUnit Users

The orgunit that the user is moved from

The orgunit that the user is moved to

Remove user

OrgUnit User Remove

The orgunit that contains the user

Link users

OrgUnit Users

The orgunit

The orgunit(s) that contain the user(s) that are to be linked

Unlink users

OrgUnit Users

The orgunit

Link or unlink effective roles

OrgUnit Roles

The orgunit

The roles that are to be linked to or unlinked from the orgunit

Link or unlink proposed roles

OrgUnit PropRoles

The orgunit

The roles that are to be linked to or unlinked from the orgunit

Activate or revoke inherited effective roles

OrgUnit InherRoles ActRev

The orgunit

The inherited roles that are to be activated or revoked

or

OrgUnit InhRoles ActRev Extended View

The orgunit

Activate or revoke directly linked proposed roles

OrgUnit PropRoles ActRev

The orgunit

The proposed roles that are to be activated or revoked

Activate or revoke inherited proposed roles

OrgUnit PropRoles ActRev

The orgunit

The inherited proposed roles that are to be activated or revoked

or

OrgUnit PropRoles ActRev Extended View

The orgunit

Link or unlink supervisor roles

OrgUnit Owner

The 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.

 

Task BHOLD Permissions Supervision

Create user

OrgUnit User Create

The orgunit that the new user is to be created under

Modify user attributes

User Modify Attributes

The orgunit that contains the user

Reset user password

User password Reset

The orgunit that contains the user

or

User password Reset All

View All

None required: enables password reset on all users

Move user

OrgUnit Users

The orgunit that the user is moved from

The orgunit that the user is moved to

Remove user

OrgUnit User Remove

The orgunit that contains the user

Link or unlink roles

User Roles

The orgunit that contains the user

The roles that are to be linked to or unlinked from the user

Activate or revoke inherited effective roles

User InhRoles AcRev

The orgunit that contains the user

The inherited roles that are to be activated or revoked

Activate or revoke inherited proposed roles

User PropRoles AcRev

The 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.

 

Task BHOLD Permissions Supervision

Create auditor

Application Owner

The application for which the auditor is to be created

Modify auditor

-

The application for which the auditor is to be modified

View auditor reports

View All

None required

Remove auditor

Application Owner

The 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.

 

Task BHOLD Permissions Supervision

Manage attribute types

Maintain Attributes

None required

Manage attribute type sets

Maintain Attributes

None required

Manage data types

Maintain Attributes

None required

Manage message translations

Maintain Attributes

None required

Manage object types

Maintain Attributes

None required

Manage orgunit types

Maintain OrgUnit Types

None required

Manage system parameters

SysInfo

None required

Queue background processes

SysInfo

None required

Manage B1Queue

SysInfo

None 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 Permission

Tasks

Do All

Users 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 Attributes

Users 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

SysInfo

Users who have this permission can perform the following tasks:

  • Manage system parameters

  • Queue background processes

  • Manage B1Queue

View All

Users 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

BHOLD Core registry settings

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

 

Name Description Default Value

B1EnforceABARepeatInterval

The number of days between attribute-based authorization (ABA) runs

01

B1EnforceABAStarthour

The hour (using a 24-hour time notation) when each ABA run will occur. For example, 23 for 11:00 p.m.

01

bholdAuthentication

The authentication method for the BHOLD website. The following values are acceptable:

  • Basic

  • Certificates

  • WindowsCertificates

  • WindowsPasswords

WindowsPasswords

bholdDirectory

Location of the BHOLD software

Specified during installation.

bholdDomain

Domain name for the user accounts

Domain or server name specified during installation

bholdGroup

The 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

BHOLDSite

The location of the BHOLD web site

/BHOLD/bhold.aspx

BHOLDUser

Name of the BHOLD Core service account

Specified during installation

NoDBVersionCheck

Disables checking the version of the database

N

Reports

Enables the Reports menu item

N

Scriptserver

Domain of the server

Specified during installation

ScriptService

The service for scripting

BHOLD

ServiceInterval

The interval (in seconds) between runs of the b1service service

10

SMTPMailFrom

The email address of the BHOLD representative

Specified during installation

SMTPServer

The server address of the SMTP (email) server

Specified during installation

SQLDatabase

The name of the SQL Server database

Specified during installation

SQLServer

The name of the SQL Server

Specified during installation

SQLConnectionString

The ODBC connection string

Not present by default. This is used only during setup when using SQL security. This value is encrypted after the b1service has started during installation

SQLConnectionStringEncrypted

The encrypted ODBC connection string

Not present by default. This is used only when using SQL security. This value is the encrypted version of SQLConnectionString.

UnAssignedTaskInterval

The expiration time (in seconds) of activated application permissions of users

5

webDirectory

The directory where the BHOLD web site is located

The location specified in BHOLDDirectory concatenated with \web

webName

The name of the virtual directory in Microsoft Internet Information Services (IIS)

BHOLD

webServer

The application server that publishes the BHOLD web site

The name of the server on which BHOLD is installed

WebVDIR

Whether IIS uses a virtual directory for the BHOLD web site

Y

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

 

Name Description Default Value

XSLdirectory

Location of the Styles directory

Specified during installation

BHOLD Core web site settings and entry points

BHOLD Core uses the following virtual web directories:

 

Web name Location Remarks

BHOLD

<BHOLD Root>\Web

The normal website

(optional)Styles

<BHOLD Root>\web\Styles

Location for XSL style sheets

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

 

Attribute Settings

Name

BHOLD

Path

<BHOLD Root>\Web

AccessSSL

True

AuthAnonymous

False

AuthBasic

True

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

 

Attribute Settings

Name

BHOLD

Path

<BHOLD Root>\Web

AccessSSL

True

AccessSSL128

False

AccessSSLNegotiateCert

True

AccessSSLRequireCert

True

AccessSSLMapCert

False

AuthAnonymous

True

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

 

Attribute Settings

Name

BHOLD

Path

<BHOLD Root>\Web

AccessSSL

True

AccessSSL128

False

AccessSSLNegotiateCert

True

AccessSSLRequireCert

True

AccessSSLMapCert

True

AuthAnonymous

True

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

 

Attribute Settings

Name

BHOLD

Path

<BHOLD Root>\Web

AccessSSL

False

AuthAnonymous

False

AuthNTLM

True

The Styles website has the following settings:

 

Attribute Settings

Name

Styles

Path

<BHOLD Root>\Web\styles

AuthAnonymous

True

The BHOLD Core website has two entry points:

 

Page name Function

BHOLD.aspx

Entry point to the user-interface

B1ScriptService.asmx

Entry point to the scripting functions

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft