One-shot interaction model

In the one-shot interaction model, each HTTP request is checked in the Airlock Gateway by calling a dedicated One-shot end-point in Airlock IAM. It is thought to verify authentication tokens obtained from other systems.

Properties of the example

  • The client has obtained a valid access token from another system. The access token is a JWT and sent as a bearer token in the HTTP header.
  • The session in the client is tracked with the access token.
  • The back-ends use session cookies or an authorization header with a JWT to track the user.

Sequence diagram

  • Used colors
  • Yellow: external view
  • Green: internal view

Both views are independent and can use different methods for session tracking, identity propagation, etc.

Airlock Gateway translates the external session to the internal session used by the back-end applications. No session information from the back-end is sent to the client.


  1. Unauthenticated access to back-end:
    • First, the Airlock Gateway checks the request and applies the configured filter rules.
    • It then checks the required roles in the mapping configuration.
    • If the Airlock Gateway session does not bear the required role, Airlock Gateway calls the IAM One-shot end-point (without returning first to the frontend application).
    • Airlock IAM checks the validity of the JWT and perform the configured identity propagation (also a JWT), and sets a new Gateway role.
    • The JWT and the role are stored in the Gateway session storage.
    • Then the request is sent to the back-end including the generated JWT.
    • The back-end application extracts the user id from the JWT.
  2. Authenticated access to backend:
    • In subsequent calls on the same session, Airlock Gateway already has the required roles and forwards the request directly to the backend without calling Airlock IAM first.