Maker–Checker Authorization Workflow

In the regular administrative workflow (without maker–checker authorization), administrators can perform any administrative commands (if they have the respective privileges), which are then executed and completed immediately. If maker–checker authorization is enabled, administrative commands are not completed immediately, but scheduled to be authorized.

The maker–checker authorization process requires two different individuals to complete a transaction; in the context of OneSpan Authentication Server, this means completing any of the following administrative commands:

• Creating a user account
• Deleting a user account
• Assigning an authenticator
• Unassigning an authenticator

Each command can be configured separately to require maker–checker authorization. If maker–checker authorization is enabled, respective commands are initiated by one administrator (maker) and can only be executed after approval and authorization by another administrator (checker).

Figure: Maker–Checker authorization workflow

Maker–checker authorization workflow

1. An administrator—the maker administrator—initiates an administrative command. When scheduling a command, the maker designates another administrator—the checker administrator—to confirm and authorize the pending operation.

2. For the scheduled command a pending operation is created and stored, awaiting authorization by an administrator other than the one who initiated the command.

   Some resources might get flagged as reserved for the pending operation and become unavailable for regular use, e.g. a designated authenticator is reserved for an assignment operation.

3. The designated checker receives a notification that a new pending operation has been created and awaits approval (pending operation created notification).

4. The checker verifies the pending operation and either approves or rejects it.

   • If the pending operation is approved (see Approving a pending operation):

     1. The state of the pending operation changes to Approved.

        If the maker administrator specified to execute the pending operation automatically upon approval when creating it, the pending operation is automatically executed now on the maker's behalf. The next steps are done implicitly.

     2. The maker receives a notification that the pending operation has been approved (pending operation approved notification).

     3. The maker can now complete the pending operation (see Executing an approved pending operation).

        Once completed, the pending operation is deleted.

   • If the pending operation is rejected (see Rejecting a pending operation):

     1. The maker receives a notification that the pending operation has been rejected (pending operation rejected notification).
     2. The pending operation is deleted.

5. A pending operation can be deleted at any time by an administrator with the respective privileges (see Deleting pending operations).

   1. The pending operation is removed.
   2. Any resource reserved for the pending operation becomes automatically available for regular use again, e.g. an authenticator reserved for an assignment operation.
   3. The maker and the designated checker receive both a notification that the pending operation has been deleted (pending operation deleted notification).

Additional considerations

• The administrator who initiates the command and the one who approves it cannot be the same.
• Only the administrator who originally initiated the command can complete it after its approval.
• Only administrators with the Approve/Reject Pending Operation privilege can be selected as designated checker or can effectively authorize pending operations.
• A pending operation can be effectively approved or rejected by either the designated checker or any other privileged administrator within the same (valid) administrative scope as the pending operation.
• A pending operation can be deleted at any time by any administrator with the Delete Pending Operation privilege within the same (valid) administrative scope as the pending operation.
• A checker administrator is not allowed to modify a pending operation itself, but may add a note with comments and suggestions for the maker.
• The settings for a user account or authenticator must not be modified while an associated operation is awaiting authorization, e.g. an authenticator must not be moved to a different organizational unit while its assignment operation is pending. In this case, the pending operation will fail and will be removed from the list of pending operations.
• The notifications for the maker–checker authorization workflow are sent using the Message Delivery Component (MDC). You can customize the message templates used for the notifications in the global configuration settings.