You are here

Authentication Enforcement

With its upstream authentication enforcement, Airlock enables centralized access control, separated from business logic. This increases security while reducing costs. Only authenticated and authorized connections are permitted to the relevant application servers. Existing directory services can be smoothly integrated.

By separating authentication and business logic, you can:

  • protect applications that were not designed for strong authentication.
  • change or add an authentication method without touching your applications.
  • offer Single Sign-On (SSO) across different applications in a heterogeneous environment.
  • streamline deployment by quickly adding new applications to a SSO domain.
  • control which applications a user is allowed to access, using role-based access control.
  • save costs by concentrating on the development of business logic.

What is an authentication service?

An authentication service is basically a web application behind Airlock. It shows the login form(s) to the users and checks their input. For this purpose, it connects to any kind of user directory (like a LDAP directory, SQL database, Radius server etc.). To inform Airlock that a user has correctly logged in, the authentication service finally adds a special cookie to its HTTP response (see Control API).

Authentication Service Architecture

Identity delegation and on-behalf login

If authentication is done by Airlock, how does the application know who the user is? The solution is to send information about the user (sometimes even his password) to the Web application, so the user will not have to log in twice. Airlock supports different ways of sending the user details to the web application, also known as identity propagation methods:

  • An HTTP header is added to every request (e.g. a cookie, a basic-authentication or an arbitrary HTTP header).
  • A Kerberos ticket (containing the user principal) is sent with each request.
  • The authentication service performs the back-end login for the user (e.g. by filling out a login form using the user's credentials). The authentication service then collects any session cookies and Airlock sends them to the web application with each request. Of course, the user does not see that login form, the on-behalf form login is done behind the scenes.

As each application may require its own way of identity delegation, Airlock allows to use a different option per application.

Airlock Authentication Service

The Airlock Authentication Service is our own implementation of an authentication service to be used with Airlock. Here is a description in detail.

Third party authentication services

As mentioned above, the Airlock Authentication Service is just one implementation of the Control API. You could of course build your own authentication service by adding just a few lines of code to your login pages. Many customers and partners have developed their own authentication service this way.

As an alternative to the Airlock Authentication Service, you might also consider one of the generic authentication services listed below.

Modular authentication service:
Supports several authentication methods including TAN, iTAN, SMS/mTAN, Challenge/Response, Federated Identities (SAML), PKI (X.509). Medusa can act as a Radius server and/or client.

Please contact us if you think your authentication service should be listed here.

Further reading

Knowledge Base Categories: