Airlock Microgateway 4.X for Airlock IAM configuration

One primary use case for Airlock Microgateway is to protect applications such as Airlock IAM against attacks.

For Airlock IAM to work correctly, it requires information about the connection between the browser (or other HTTP client) and first server-side HTTP endpoint. Such information includes client IPs, URL paths, and client certificates.

Unlike classic Airlock Gateway deployments, in Microgatway deployments, the information may come from different sources: a load balancer, an ingress controller, or the Microgateway itself. The information needs to be collected at the point in the network architecture where the TLS connection is terminated (e.g., the ingress controller) and forwarded in the correct format so that the Airlock Microgateway and Airlock IAM can process it.

Integrating Airlock IAM behind Airlock Microgateway 4.X is an ongoing project and will see many improvements over time.

Supported Features

  • Airlock IAM supports the following features if used with Microgateway 4.X:
  • It is possible to configure the following HTTP header extractors:
    • HTTP Request Client IP Extractor is used by IAM in risk-based authentication and for logging purposes.
    • HTTP Request ID Extractor is used by IAM for log correlation purposes.
    • HTTP Request URL Extractor is used by IAM to create URLs, e.g., in OAuth 2.0 redirects and REST responses.
    • HTTP Request mTLS Client Certificate Extractor is used by IAM to verify the client, e.g., in OAuth 2.0. It is used in OAuth/OIDC use cases and to authenticate REST requests sent to IAM REST APIs.
  • CSRF protection, as provided by Microgateway, can be used with Airlock IAM.
  • The following features are handled by Airlock IAM independent of Microgateway:
  • Session Idle Timeout and Session Lifetime are configured for Loginapp and Adminapp and enforced by IAM locally. These timeouts are synchronized across IAM instances if used with the Redis session store.

    • In setups with Airlock Gateway, session idle timeout and session lifetimes are enforced by the Gateway using the values configured in the Gateway.

    When migrating from a Gateway to a Microgateway setup, please make sure to verify the configuration of session idle timeout and session lifetime in Airlock IAM.

  • The following context extractors are supported if IAM is used behind an Airlock Microgateway:
  • IP Address Context Extractor
  • URL Context Extractor
  • Static Context Extractor
  • HTTP Parameter Context Extractor
  • Combining Context Extractor (as long as only extractors from this list are used)
  • Concatenating Context Extractor (as long as only extractors from this list are used)
  • No Context Extractor

Currently, other than the above-listed types of context extractors are not supported. However, it is possible that additional context extractors will be included in future versions.

Configuration Airlock IAM

By default, Airlock IAM is configured to be run behind an Airlock Gateway. To change this setup and use a Microgateway instead, follow these simple steps:

  1. To change this setup and use a Microgateway instead, follow these simple steps:
  2. Go to
    Loginapp
  3. In property Gateway Settings add a plugin of type Airlock Microgateway Settings
  4. Go to
    Adminapp
  5. In property Gateway Settings add a plugin of type Airlock Microgateway Settings

The Airlock Microgateway Settings plugin is automatically configured for Airlock Microgateway.

Microgateway configuration

  • To configure the Microgateway a Helm chart is provided that configures the following features:
  • Deny rules to protect IAM against attacks.
  • CSRF feature of the Microgateway is enabled.

The Helm chart can be obtained from github: Microgateway Helm chart for IAM.

Known limitations

The following limitations apply when using Airlock IAM with Airlock Microgateway 4.X. The features are available if using Airlock IAM with Airlock Gateway.

  • The Microgateway does not yet support session management and therefore is not ready to enforce access control (e.g., by granting roles on a session).
  • The Microgateway does not support protecting multiple applications. It is therefore not possible to implement identity propagation via the Microgateway. However, identity propagation using OIDC, OAuth, SAML, or SSO tickets is possible even if Airlock IAM is used behind Airlock Microgateway.
  • The Microgateway does not support a cookie store and cookies created by IAM are sent to the client.
  • IAM does not support One-Shot authentication behind a Microgateway.
  • IAM does not support the Client Certificate Context Extractor.
  • Client certificates from mTLS are expected as URL-encoded PEM certificates in an HTTP request header. The name of the header is configurable but not the format. They are used in OAuth/OIDC use cases and to authenticate REST requests sent to IAM REST APIs.
  • Client certificates can be used for request authentication (Adminapp and Transaction Approval REST APIs) and in dynamic client registration in the Loginapp.