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 the first server-side HTTP endpoint. Such information includes client IPs, URL paths, and client certificates.

Unlike classic Airlock Gateway deployments, information in Airlock Microgateway deployments may come from 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.

Supported Features

Airlock IAM supports the following features if used with Microgateway 4.1 and later.

  • Configuration of 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. PEM and XFCC formats are supported – for more information, see IAM plugin documentation.
  • 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, 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:
  • Client Certificate Context Extractor
  • 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, only the above-listed types of context extractors are supported. However, future versions may include additional context extractors.

Configure Airlock IAM for Microgateway

By default, Airlock IAM is configured to be run behind an Airlock Gateway. To be able to work with the Airlock Microgateway, the following set-up steps must be carried out.

  1. Go to:
    Loginapp
  2. In property Gateway Settings add a plugin of type Airlock Microgateway Settings
  3. Go to:
    Adminapp
  4. 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 Airlock IAM against attacks.
  • CSRF feature of the Airlock 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.1 and later:
  • 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, so it is not possible to implement identity propagation ​via​ it. However, identity propagation using OIDC, OAuth, SAML, or SSO tickets is possible even if Airlock IAM is used behind the 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.
  • Client certificates can be used for request authentication (Adminapp and Transaction Approval REST APIs) and in dynamic client registration in the Loginapp.

The features are available if using Airlock IAM with Airlock Gateway.