IAM modules and databases/directories

This content gives an overview of Airlock IAM modules and the way they are typically used.


The following picture shows the main modules of an IAM instance.

Airlock IAM Database

Multiple instances can be created. Each instance runs in a separate web server process.

During the installation, a default instance named "auth" will be created. Additional instances can be created using the command-line interface.

Loginapp UI + REST API

The Loginapp module offers a web application and a Loginapp REST API for authentication.

Adminapp UI + REST API

The Adminapp module offers a web application and Adminapp REST API for user- and token management, configuration, log viewer, and admin management.

Service Container

The Service Container module is a web application to executes periodical tasks and runs the RADIUS server.

Common usage is:

  • Run the RADIUS server: Provide any authentication scheme(s) via the integrated RADIUS server.
  • Batch-generation of password letters, token letters, or any other user-related reports.
  • Batch-generation of Airlock 2FA enrollment letters.
  • Batch-generation of matrix cards.
  • Batch-generation of QR code letters for OATH OTP token enrollment.
  • Send generated reports directly to printers (requires printer system plugin).
  • Import users from external directories or export user data to other directories or databases.
  • Run regular tasks on user data (e.g. account cleanup tasks).

Transaction Approval

The Transaction Approval module exposes a REST API that allows 3rd party systems (e.g. e-banking system) to verify transactions by sending transaction details to the end-user using second-factor authentication tokens (e.g. approve banking payment).

It is meant to be used as an internal infrastructure, e.g. invoked from an e-banking system acting as a delegating entity on behalf of a user and not to be exposed directly to the internet.

API policy service

The API Policy Service REST service is called by the Airlock API gateway in order to get information about Tech-Clients.


Airlock IAM stores various types of information such as user- and authentication token data in a persistence layer.

Airlock IAM is made to work with relational databases and with LDAP directories (including Microsoft’s ActiveDirectory). Corresponding database schemas and persister plugins are delivered with IAM.

The database (or directory) for productive systems is not part of Airlock IAM. Airlock IAM is not responsible for the operation and backup/recovery of the persistence layer. This is also true if the H2 database shipped with IAM is used.

Choosing the type of user data source influences the set of features that can be used.