Front-side Kerberos authentication

With front-side Kerberos, Airlock IAM authenticates users based on a Kerberos ticket. This allows the implementation of single sign-on in Windows environments for all target applications connected to Airlock IAM without the need to make them Kerberos-aware.


The following image shows the basic steps to authenticate users with Front-side Kerberos authentication against Airlock IAM:

Frontside Kerberos

  1. The user requests access to the back-end application Web App A which is protected by Airlock Gateway. This web application is accessible through the virtual host Authentication enforcement is configured on Airlock Gateway. Since the user is not yet authenticated the request is passed to Airlock IAM.
  2. Airlock IAM receives the request from 1). Because it does not contain a Kerberos ticket, Airlock IAM asks for such a ticket by responding with HTTP 401 and the necessary header to trigger Kerberos authentication in the browser.
  3. Now the browser requests a Kerberos service ticket for the service from the Active Directory domain controller.
  4. The browser repeats the request from 1) and appends the Kerberos service ticket received in 3) from the Active Directory domain controller. The user is still not authenticated, so the request is passed again to Airlock IAM.
  5. Airlock IAM receives the request which has now a Kerberos service ticket appended and verifies whether the ticket is valid or not and extracts information from it.
  6. In case the user has sent a valid Kerberos ticket, Airlock IAM additionally validates the user through LDAPS in the Active Directory. If necessary, additional group membership checks, etc. can be performed at this point. After the user has been successfully authenticated, Airlock IAM sets the necessary Gateway roles and the information for identity propagation to the target application.
  7. Because the user is now authenticated, the original request can now access the desired back-end application. From now on, the user's session is authenticated, so further requests are passed directly to the back-end application.

Please note that this example illustrates the One-Shot authentication flow. In the case of the Redirect authentication flow, the sequence looks a bit different.