4 Eyed Principle

In Sterling B2B Integrator, the 4 eyed principle allows you to add or update resources and make them available to user only after approval from at least one another administrator, who is a Super User.

The 4 eyed principle is a widely used internal control mechanism that requires that any activity by an individual within the organization must be controlled (reviewed and double checked) by a second individual that is independent and competent.

It offers an extra layer of security to all the critical resources of Sterling B2B Integrator such as User Accounts and Business Processes.

Enabling 4 eyed principle

A new property, enable.4eyedPrinciple is introduced to enable the 4 eyed principle in Sterling B2B Integrator. You can configure the property in the security.properties file. This property enables the Approval process for User Accounts and Business Processes.

The valid values are userAccount and businessProcess.

The syntax is:

enable.4eyedPrinciple=val1,val2.. 
For example: 
enable.4eyedPrinciple=userAccount,businessProcess
You can use one of the following methods to use the 4 eyed principle feature in Sterling B2B Integrator:

In case of User Accounts, when you enable the 4 eyed principle, the newly created User Account is inactive and a request is raised. You must contact the administrator for approval to make the User Account active. Additionally, the User Account must go through the Approval process when you modify the User Account to add new permissions or groups.

In case of Business Processes, when you enable the 4 eyed principle, the newly created Business Process is inactive and a request is raised. You must contact the administrator for approval to make the Business Process active. Additionally, the Business Process must go through the Approval process when you modify the default version.

Important:
  • A user cannot approve or reject his own request. Only a Super User or a user with specific permission for approval management can review and approve/reject the requests.
  • You must turn off the enable.4eyedPrinciple property during installation or upgrade. You can turn it on after the installation or upgrade process is complete.
  • The User Account and Business Process create and update operations are blocked though XAPI, when the enable.4eyedPrinciple property is enabled.
  • The User Account edit operation does not have any default permissions added by the system, when the enable.4eyedPrinciple property is enabled.
  • You can create multiple edit requests for a pending request for same the resource (User Account and Business Process).
  • The create and update operations of User Account using XAPI service is no longer supported when the system enables the 4 eyed principle for User Accounts. Instead, the REST APIs perform these operations.
  • The create and update operations of Business Process using XAPI service is no longer supported when the system enables the 4 eyed principle for Business Processes. Instead, the REST APIs perform these operations.
  • You cannot delete a User Account or a Business Process when it is waiting on pending approval request. When you attempt to delete, the system displays an error message and does not delete such resources (User Account and Business Processes).

Security permissions

The following permissions are introduced:
  • Pending Approvals - The administrator can provide privileges and assign the Pending Approvals permission to some users who can act as reviewers. This enables such users to access the Pending Approval screen in the UI and view the list of pending approval requests.
  • User Account Approval Management - The administrator can assign management permission to some users to act as approvers. This enables such users to view all the pending approval requests and approve or reject User Account requests.
  • Business Process Approval Management - The administrator can assign management permission to some users to act as approvers. This enables such users to view all the pending approval requests and approve or reject Business Process requests.

Purge service

The system allows to periodically purge unwanted data from the system and prevent possible bottleneck in the database.

A new property, purge_approvalRecordInterval is introduced that controls the lifespan of the approval records to be purged. You must include this property in the archivethread.properties_hpp_ext file. The default value is 30 days.

All the data of the approval requests is stored in APPROVAL_ACTIVITY and DATA_TABLE.

Upon execution of the external purge command, ./control_extpurge.sh, the purge operation removes all approval records whose state is either approved/rejected and older than 30 days based on reviewed date. The system purges all data present in APPROVAL_ACTIVITY and the corresponding data in DATA_TABLE that is in APPROVED/REJCETED state, whose review date is greater than 30 days.