You are here

Airlock Authentication Service

Affects product: 
Authentication Service
Affects version(s): 
all versions

The Airlock Authentication Service is our own implementation of an authentication service to be used with Airlock. This article lists the features of Version 2.x.

The Airlock Authentication Service is replaced by Airlock Login. The Airlock Authentication Service is not going to be continued anymore but will be supported until September 2016.


Authentication methods
User directories
Identity and role mapping


Authentication methods

Airlock supports any authentication method. It controls access to all protected applications, but the actual authentication is delegated to an authentication service.

Airlock = Policy Enforcement Point (PEP)
Authentication Service = Policy Decision Point (PDP)
The Airlock Authentication Service supports the following authentication methods as building blocks:

  • User-ID + Password (see supported user directories below)
  • Multi-factor authentication (e.g. one-time passwords)
  • PKI/X.509 Client Certificates (either soft or hard tokens)

These authentication methods can be combined. The table below shows how the authentication method depends on user directories.


After a user is authenticated, you often want to control which applications (or even parts of an applicaiton) he can access. With the Airlock Authentication Service, you have unlimited ways of restricting access to a web application - basically any information stored in a user directory can be used as a decision base.

For example, you could restrict access to

  • a list of user groups
  • users having a certain attribute (e.g. only users with the LDAP attribute CRM_Access)
  • users with a certain Email address or domain
  • users logging in from an IP address in a defined range (e.g. the intranet).
  • a time frame (time of day or weekdays)

Any combination of these restrictions can be enforced globally (SSO domain) or per application.

User directories

The Airlock Authentication Service can connect to one or more servers to check user credentials and permissions.

The following table lists the currently supported user directories and the corresponding features. While reading it, keep in mind that you can

  • connect to different directories to combine any authentication method with another one
  • use one directory for authentication and another for authorization
  • configure multiple directories of the same type (for high availability or load balancing scenarios)
Directory or authentication server Authentication features  Authorization features

- Active Directory
- Novell eDirectory
- Siemens DirX
- Sun Directory Server
- OpenLDAP

  • check user ID + password (LDAP bind)
  • check if user exists (search for a user ID, Email address, certificate etc.)
  • check if user belongs to a given role/group
  • look up any user attribute
  • execute an arbitrary LDAP query
  • evaluate the result or use it for further queries


- Oracle
- MS SQL Server
- Postgres

  • search user by any number of fields (customizable SQL query)
  • check password (plaintext or hashed)
  • check if user belongs to a given role/group (customizable SQL query)
  • execute a custom SQL query and check if at least one row is returned
  • execute a custom SQL query and use the results for further queries/checks

Text File

e.g. a properties file

  • check user ID + password
  • search user by any key
  • check user properties
  • check user roles
Radius Server
  • check user ID + password
  • check any additional authentication factor, like a one-time password (e.g. TAN)
A Radius server cannot make authorization decisions. But Radius authentication can be combined with authorization based on any information including other user directories.
  • check user ID + password + token
  • check user ID + token only
An RSA server cannot make authorization decisions. But RSA authentication can be combined with authorization based on any information including other user directories.
  • Low cost two-factor authentication
  • Delegate authentication to ELCARD
  • User is presented a challenge and enters his secret path on the virtual keyboard
An ELCARD server cannot make authorization decisions. But ELCARD authentication can be combined with authorization based on any information including other user directories.
Custom Implement any authentication method or authorization restriction by writing a plug-in and deploy your code together with the Airlock Authentication Service. The plug-in written in Java must implement the API described in the Airlock Authentication Service SDK (contained in the download package).

Identity and role mapping

Out of every bit of information regarding an authenticated user, the Authentication Service can make decisions for rules, timeouts, audit tokens, redirects and so on. The information about the user is typically taken outside the user directory. But it has not even to be same user directory as the one which authenticated the user. Decisions could be based for example on a Web Service, another database etc.


  • If the user is in the LDAP group CN=management, the Airlock role mgt will be granted. This gives the user access to the CRM system, for which Airlock requires the role mgt on the corresponding Mapping.
  • If the user is connecting from an IP address within the intranet range, a higher timeout will be given to this user.


The Airlock Authentication Service is sold as an optional module for Airlock.
For sales inquiries, please contact


The Airlock Authentication Service may be deployed either

  • on Airlock (in a small, preconfigured application server) or
  • on any other Java application server you already have in place.

Life cycle

The Airlock Authentication Service is versioned and released independently from Airlock.


The Airlock Authentication Service manual is available here. Premium Partners may download the latest release of the Airlock Authentication Service here.

Knowledge Base Categories: