Protecting Airlock IAM with separate Microgateways and JWT access tokens

This setup provides the highest degree of decoupling between the Microgateways and Airlock IAM. Access control is performed using the JWT access control features of the Microgateway. Airlock IAM acts as an IDP, issuing the tokens. A common Redis database for session synchronization is not required.

Depending on how the JWTs are transferred, certain limitations may apply. If the tokens are transferred using cookies, domain restrictions enforced in browsers apply. That is, the SSO will not work across multiple domains. Another option is to transfer tokens using HTTP headers. Clients extract the tokens and attach them to subsequent requests. This works in cross-domain scenarios, as well. However, it requires clients to be aware of the tokens and to handle them securely.

• Similar to Separate Microgateway for each service, which means, that the same arguments apply here.
• Separate Microgateway for Airlock IAM and each service.
• The Airlock Control API is not used.
• Airlock IAM issues a JWT containing roles instead of attaching the roles to a session.
• JWT access control features of the Airlock Microgateway are used.

In the community edition, JWT access tokens are only available in the "log only" mode. That is, requests with invalid tokens are not stopped.