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
.
enable.4eyedPrinciple=val1,val2..
For example:
enable.4eyedPrinciple=userAccount,businessProcess
- UI
- REST APIs
For more information, see B2B REST APIs available 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.
- 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
- 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.