The Correlation ID links incoming HTTP requests with outgoing requests and log files by using a consistent reference ID. This ensures that all actions stemming from a specific user request are grouped together, enhancing the traceability of the use case through IAM and third-party systems. Example use cases include transaction approval procedures or authentication processes using the Airlock 2FA app as a second factor.
How does the correlation ID work?
At the beginning of a specific transaction, an upstream third party system of Airlock IAM generates an ID and sends this ID in the HTTP request header to IAM. IAM logs this ID as corr_id
in its log files. Additionally, IAM forwards the ID unchanged to the downstream third party system(s) that follow in the transaction process.
The following graphic illustrates the functioning of the Correlation ID feature. Within IAM, the feature is supported by all modules (Loginapp, Adminapp, Transaction Approval, etc.) as well as all plugins that define HTTP calls to third party systems.
The responsibility for generating the correlation ID lies with the third party system that precedes IAM in the transaction flow. This upstream system determines which correlation ID to set where and when in the incoming request to IAM. IAM only receives, logs and forwards the correlation ID (if configured).
If the incoming HTTP request does not contain a correlation ID, IAM will not generate one itself. In this case, no correlation ID will be available for this specific transaction.
To preserve backward compatibility, the corr_id
is only set in the structured log by default (status Q3 2024). It is possible to also log the correlation ID in the Main log, but this requires a manual configuration - for instructions, see further below.
The correlation ID is currently not supported for the parsable log files (used by the Adminapp log viewer).
Within IAM, the X-Correlation-ID
header field is set as the default HTTP header field to transfer the correlation ID. However, the X-Correlation-ID
header is no general standard. It is possible to use another header for the incoming and/or outgoing correlation ID, if you or your third party systems would prefer this.
Also, the HTTP header field containing the incoming correlation ID does not have to be the same as the HTTP header field containing the outgoing correlation ID. This allows for greater flexibility in adjusting your settings to those of your third party systems.