Access control for protected services is an important use case of the Airlock Microgateway. Existing identity services can be integrated using JWT access tokens. However, a close integration with Airlock IAM offers many benefits and unlocks a rich set of IAM functionality for Airlock Microgateway deployments.
This chapter provides integration blueprints. Basic knowledge of Airlock IAM is assumed as a prerequisite.
There are different architectural approaches for integrating Airlock IAM. The most important design choice is whether the protected service(s) and Airlock IAM share the same Microgateway or not. The discussion is similar to the architectures outlined: Cascaded services
When integrating Airlock IAM, there is SSO state to be synchronized between Airlock IAM and the services. SSO state refers to state information regarding authentication and authorization decisions. If user authentication is involved, the results of authentication steps must be remembered during the user interaction. Adaptive enforcement of authentication steps allows implementation of step-up or risk-based authentication policies.
When using a centralized approach with a single Microgateway, the SSO state is centrally available on the only Microgateway. However, this approach lacks separation of Airlock IAM and service deployments.
These roles constitute the SSO state that needs to be synchronized. Synchronization is achieved either by using the Airlock Control API and a common Redis session store or by using standardized JWTs as access tokens.
The Airlock Minikube example uses separate Microgateways, demonstrating both: session synchronization using Redis and access control using JWT access tokens.