The Transaction Approval (TA) module runs as a separate IAM application on the runtime platform and exposes a REST API under the /transaction-approval path. Because this API can be used to initiate and process approval flows, it must be protected against access by untrusted callers.
ⓘ Note that the TA module is optional and deployed only on request.
The TA module exposes only REST endpoints and has no user interface. The endpoints are intended to be called by the customer’s trusted back end and are reachable at:
https://transactionapproval-<tenantId>.airlock.cloud/transaction-approval/rest/transaction-approval/...REST calls must include the X-Same-Domain header for CSRF protection. Each request is also validated against the TA OpenAPI specification, so the request path and body must match the specification.
How the TA endpoint is protected
Inbound protection for the TA module can be configured at two independent layers:
Transport layer: Mutual TLS (mTLS) in the Airlock Console TLS settings.
Application layer: Request authentication in the tenant IAM configuration (YAML or XML) contained in the uploaded configuration ZIP file.
Before activating the tenant, configure at least one of these protection mechanisms.
Warning
The SaaS platform does not enforce inbound authentication for the TA module and does not block deployment or activation if no protection is configured. If neither mTLS nor application-level authentication is configured, the TA endpoint is exposed to the public internet.
➔ Securing the TA endpoint is the responsibility of the configuration owner.
Laye 1: mTLS (recommended)
Mutual TLS authenticates the calling client at the transport layer. This is the recommended option because the client must present a valid client certificate before any application logic is executed.
Configure mTLS for the TA module separately for each tenant in the Airlock Console under:
TLS Settings >> Transaction Approval >> Mutual TLS
Warning
If a tenant is activated before mTLS or another protection mechanism is configured, the deployed TA module is exposed to the public internet.
➔ Configure mTLS before activating the tenant.
Layer 2: Request authentication in the IAM configuration
ⓘ Note that if mTLS is not available, we strongly recommend configuring application-level authentication for the TA module.
The TA module’s requestAuthentication property determines how REST requests to the TA endpoint are authenticated at the application layer. It is configured in the tenant IAM configuration and works independently of mTLS. As a result, it can protect the endpoint even when mTLS is not configured.
Use the BasicAuthRequestAuthenticationConfig plugin to require HTTP Basic authentication for all requests to the TA endpoint. The supplied credentials are validated against the configured user store and password repository.
The credentials are protected in transit by the server-side TLS connection terminated at the Gateway. Therefore, HTTP Basic authentication can be used over a standard TLS connection without mTLS.
Verifying the protection
Send a test request to the running TA endpoint to verify that the protection is active. If HTTP Basic authentication is configured, requests without credentials or with invalid credentials receive an HTTP 401 response and do not reach the TA flow.