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: The Transaction Approval module is an optional component and only deployed on request.
How the TA endpoint is protected
Inbound protection for the TA module can be configured at two levels:
Transport-level mutual authentication in the Airlock Console TLS settings.
Application-level protection in the tenant’s YAML or XML configuration contained in the uploaded configuration ZIP file.
These layers are independent of each other. We strongly recommend configuring at least one of them before activating the tenant.
Warning
The SaaS platform does not enforce inbound authentication for the TA module. It neither blocks deployment nor activation if no protection is configured. As a result, a TA module that is left unprotected in the tenant configuration is exposed to the public internet. Securing the endpoint is the responsibility of the configuration owner.
Layer 1: mTLS (recommended)
Mutual TLS authenticates the calling client at the transport layer. This is the recommended option because the client proves its identity with a certificate before any application logic is executed.
Configure mTLS for the TA module per tenant in the Airlock Console under:
TLS Settings >> Transaction Approval >> Mutual TLS
Configure mTLS before activating the tenant. Until mTLS (or another protection mechanism) is configured, a deployed TA module is exposed to the public internet.
Layer 2: Request authentication in the IAM configuration
ⓘ Note: If mTLS is not available, we strongly recommend protecting the TA module by authenticating incoming requests.
The TA module’s requestAuthentication property determines how inbound REST requests are authenticated at the application layer. It is configured in the IAM configuration and is independent 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 inbound requests. The supplied credentials are validated against the configured user store and password repository. The credentials remain protected in transit by the server-side TLS connection terminated at the Gateway. As a result, HTTP Basic authentication can be used securely over a standard TLS connection without mTLS.
Verifying the protection
A quick check against the running endpoint confirms whether the protection is in place. If Basic Authentication is configured, requests without credentials or with invalid credentials receive an HTTP 401 response and do not reach the flow.