The transaction approval module exposes a REST API that allows a delegating entity to verify transactions with the user's 2nd authentication factor such as Airlock 2FA.
By the term delegating entity, we refer to 3rd party applications such as e-banking systems.
The transaction approval interface is intended to be used in the internal infrastructure. e.g. invoked from an e-banking system acting as a delegating entity on behalf of a user.
It is not intended to be exposed directly to the internet.
Transaction Approval requires the separate license bundle TRANSACTION APPROVAL.
The transaction approval process is organized and configured as a sequence of steps.
- A typical transaction approval flow is as follows:
- Flow selection – Selects the corresponding flow from the available transaction approval flows.
- User identifying step – Identifies the user to IAM.
- Parameter step and message providers – Send transaction detail to IAM.
- Selection of authentication token and authTokenId usage (optional) – If the user has multiple tokens, one must be selected for transaction approval.
- Approval steps – An authentication token (e.g. Airlock 2FA, mTAN, or Cronto) is used to send transaction details to the user and have them approved. The transaction details are formatted using a message provider.
Since IAM 7.7, multiple transaction approval flows can be configured in parallel, therefore requiring a flow selection call.
If no flow selection call is made, the flow with ID legacy-default-flow is automatically selected. This flow ID is given to the one flow when migrating from older IAM versions. Thus, existing delegating entities (that did not yet know about the flow selection call) will still work after migration to IAM 7.7 or later.
If relying on this, do not change the flow ID legacy-default-flow.