BHOLD Suite glossary



See: attribute-based authorization

access control

Maintaining control over who can interact with a resource. In the case of computer security, it involves authentication, authorization, and auditing.

activated role

A proposed role that has been made effective for a user or organizational unit.


Software for a specific purpose, for which authorizations are set. Users can have access to various parts or services of an application. Applications can use permissions to control this access.


A quality, property, or characteristic of somebody or something. In the case of BHOLD, an attribute is information about an organizational unit, user, role, application, or permission. Attributes can be defined to provide additional information about organizational units and users.

attribute-based authorization

Authorization based on a rule or a set of rules for a role that are applied based on specific attributes. For example, a user must have a specific job title to gain access to certain applications or permissions in applications.

attribute value

An allowable value of an attribute. For example, the attribute country can have such values as USA, UK, and The Netherlands.


The manual or systematic assessment of the security of a system or application. BHOLD Suite 2012 provides the Attestation, Analytics, and Reporting modules to help assess the effectiveness of the role-based access controls managed by BHOLD.


The decision-forming process to determine whether a person or thing is what that person or thing claims to be. This process ascertains whether it is appropriate for an individual to obtain certain information. See also: authorization.


Authorization is the process of issuing permissions to a person to do or have something. The process can be used to give access rights to a user, program or process. See also: delegated authorization.

B1 application


B1 queue

The queue that stores BHOLD Core commands to be executed in order. The commands are executed after an event in the B1 service, the BHOLD Core module.


Limitations to the number of simultaneous relationships which an object (such as a user, role, or permissions) can have with other objects, such as the maximum number of users that can hold a role. These limits are enforced by BHOLD Suite.

child role

See: sub-role.


The organizational unit from which a user inherits a role (and its permissions).


Discretionary access control

data integrity

The assurance that information can only be accessed and modified by those authorized to do so.

delegated authorization

Assigning to a user access rights that originally belonged to the user’s manager.


Full-time equivalent; usually used to indicate that an employee is not a temporary (contingent) employee.


Mandatory access control


In BHOLD, the supervisor responsible for an object. All objects must have at least one supervisor who can be held responsible for that object. Authority/management is implemented as a special kind of permission. Changes that would result in an unsupervised object are rejected. Supervisors cannot remove the responsibility for an object from themselves.

organization type

A classification of an organizational unit (orgunit). The organization type describes the organizational unit (for example, main office, branch office, division, project). Organization types can be used to categorize organizational units so that the organization is easier to understand.

organizational unit (orgunit)

A group of users or other organizational units. Every orgunit, except for the very first one (the root orgunit), is always subordinate to another organizational unit. By default, subordinate organizational units inherit all permissions from their parent orgunit. The members of an organizational unit share groups of permissions.


See: organizational unit (orgunit).


See: organizational unit (orgunit).

parent role

See: super-role.


The right to perform an action in an application. A role can contain more than one permission; a permission can occur in more than one role. Permissions are always part of (or are identified with) an application. Permissions can only be assigned to roles.

proposed role

A role that is not effective for a user or organizational unit until it is activated. Using proposed roles gives you the ability to selectively apply roles to a subset of users. See also: activated role.


The process of providing access for users to data and technological sources.


See: role-based access control.

role-based access control

A method of access control that provides a framework for classifying users and IT resources to make explicit their relationship and the access rights that are appropriate according to that classification. 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 data that the user needs to contribute to a particular project. When the user assumes a different job and different project assignments, changing the attributes that specify the user’s job title and projects automatically blocks access to the resources only required for the user’s previous position.


The positions a user holds in an organization. These positions can be defined as roles comprised of a collection of privileges and authorizations within that organization. A role can be assigned to a specific user as well as to an organizational unit (orgunit): each member of that organizational unit and all its subordinate units inherit these roles and thus all relevant permissions.

There are two ways to assign roles to organizational units. When you want to give a role immediately to an organizational unit that you supervise, you select the role (that you supervise) and activate it for the organizational unit. All the members of this organizational unit and all members of subordinate organizational units receive that role. Alternatively, you can select a role (that you supervise) that you feel is useful for an organizational unit and then propose it for the unit. This does not activate the role, but it does present it to the supervisors of the organizational unit as a proposed role. It is the responsibility of the supervisor of the role to activate it when it is appropriate to do so. To activate a role, the supervisor must also have the authority to view the organizational unit.

See also: super-role, sub-role, proposed role, activated role.


A role that is a member of a super-role. A role can be a sub-role of one or more other roles as well as super-role of one or more sub-roles. A role can never be both a sub-role and a super-role, directly or indirectly, of another role. Also known as a child role.


A role that contain one or more sub-roles. A user or organizational unit with a super-role also inherits the sub-roles that are linked to it. Supervisors of a role can link that role as a sub-role to other roles. Also known as a parent role.


The first, top-level organizational unit of BHOLD Core. The term <root> also refers to the user account that was used to install the BHOLD Core module. This user has certain predefined privileges for gaining access to the basic BHOLD functionality.

separation of duties (SoD)

Applies in instances where two distinct responsibilities should never be granted to the same person. BHOLD Suite implements this as incompatible permissions that may never be assigned to the one user at the same time. SoD conflicts are possible on role, organizational unit, and user levels.


See: separation of duties (SoD).


A user with the authority to manage an organizational unit, role, permission or application. The privileges connected to the status of supervisor are different for each object. In all cases, being a supervisor also means the right to make other users supervisor of the supervised object.


See: permission.

view right

The right to view certain objects within BHOLD Suite. Not all users with access to BHOLD are allowed to view all the information that is available, so BHOLD is protected by view rights.