Security

Decision Center controls access to branches of decision services, and sets permissions on the different rule artifacts.

Any user who signs in to the Business console must be a member of a group that is mapped to one of the predefined Decision Center roles. The predefined roles determine which features the user can access:

Role Description
Standard user (rtsUser) The standard Decision Center user. Provides basic use.
Configuration manager (rtsConfigManager) Has all the rights of the standard user, plus additional rights in the Business console to create and edit deployment configurations.
Administrator (rtsAdministrator) Has all the rights of the standard and configuration manager users, plus additional rights in the Business console:
  • Access the Administration tab to enable security and manage users.
  • Take on the role of any governance framework participant.
Installer (rtsInstaller) Has all the rights of the administrator users, plus additional rights in the Business console:
  • Initial installation of Decision Center
  • Run the REST API endpoints in the DBAdmin section

With administrator rights, you enable security so that branches of decision services are only visible to certain groups of users. You enable security from the Business console (see Setting project security).

When you enable security, you must specify, for each group that can access the branch, what permissions they have to create, update, view, and delete which types of artifacts. You do this from the Business console Administration tab (see Managing users from Decision Center).

Branch security and decision governance

To use the decision governance framework (see Governance principles) with the Decision Center security feature, you must understand how both work and how they interact.

Releases and activities are types of branches, and as such are subject to the Decision Center security and permissions feature. You can enable security on individual branches to define which groups of users have access to them. When security is enabled on a branch, you specify the permissions of groups of users to create, view, update, and delete the different artifacts that are contained in the branch.

Note: Branches in the decision governance framework inherit the security state of their parent branches. If you enable security on the initial release of a decision service, all the releases and activities that stem from the initial release have security that is enabled by default. Similarly, you can enforce security on a validation activity by setting security on its parent release.

Releases, change activities, and validation activities inherit artifacts from their parent branch, and are subject to permissions. You can, for example, give a group of users security access to a release but restrict their permission to view the change activities of the release.

You can also give or restrict the permissions of a group of users to update the following properties of releases and activities:

Property Function
owner Change the owner
targetDate Change the due date
description Change the goals
Name Rename
Status Proceed to approval, cancel, and reopen
approvers Add or remove approvers and change their working status
authors Add or remove authors in change activities or testers in validation activities, and change their working status
The decision governance framework provides governance aspects that are based on states and governance roles:
  • The states of releases and activities (for example, In Progress and Complete).
  • The current user's governance role as a participant in the release or activity (owner, author, tester, or approver).

A user who has administrator privileges can do the operations of all the different governance roles. Similarly, users with these privileges have access to all the branches and have all the permissions on all artifacts. However, administrators cannot force state transitions that are not allowed by the decision governance framework.

When you use the decision governance framework, some conditions are imposed, and you must take into account any conditions that are imposed by the security feature. For example, you can rename a release only under the following conditions:
  • The state of the release is not Complete.
  • You are the owner of the release.
  • You have the Update/Release/Name permission on the release, or security on the release is not enforced.