Airlock IAM Performance Tuning

There are various aspects that influence performance and ability to scale of an Airlock IAM system depending on the precise usage scenario. This article highlights the most common bottlenecks.

Audit Log

In Airlock IAM audit log signing is disabled by default. The signature ensures that manipulations of log messages are detectable. The generation of log sequence numbers and digital signatures limits scaling with the number of CPU cores. Disabling audit log signing can speed up the whole system significantly. Audit log messages are still written - but not signed anymore.

Database Selection

The system requirements page lists the supported databases. Some of them are known to scale well with the number of users or tokens. Others are fine for smaller scenarios only.

The supported H2 database has limitations:

• H2 uses only one index per logical table at a time in each query.
• The H2 cluster feature imposes additional limitations on performance (result sets are completely loaded into memory).

Database Monitoring

Database Indices

To scale well, a database needs indices that are based on the most frequent use cases. Since Airlock IAM is highly configurable regarding database fields, the indices have to be set with the knowledge of the field configuration and usage.

Airlock IAM defines indices and primary keys in the database schema setup scripts. The database schemas are not updated automatically when updating the Airlock IAM software. Changes to the database schemas have to be performed manually.

The schema files and the schema update files can be found in the IAM manual. 

DB Statistics

DB systems use optimizers to tune queries on their own. The decisions of the query optimizer base on database usage statistics. The statistics have to be up-to-date to result in the best decisions.

DB Connection Pool

Connections from Airlock IAM to the DB are handled by connection pools.

The idea is to run only as many parallel requests in the DB as it can handle at a time:

• Using too few DB connections will result in a bottleneck (wait events in IAM).
• Using too many DB connections can result in DB wait events and lower the overall performance as well.

Each configured DB connection has its own pool size. A separate connection pool is used by each module (Loginapp, Adminapp, SOAP Interface, Service Container, Transaction Approval) and connection pool configuration (e.g. pool size). The Loginapp typically needs more DB connections than the Adminapp.

See https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing for more information about connection pool sizing.

Current JDBC Driver

Database vendors provide JDBC drivers for specific versions of their databases. JDBC drivers are not bundled with Airlock IAM and must be downloaded and deployed separately. It is essential to use the  latest JDBC driver that matches the database version currently in use. Unexpected behavior including degraded performance can result from an inappropriate driver version.

Persistency Plugins

The choice of persistency plugins has an influence on the performance:

• Whenever possible favor using User Store plugins over User Persister plugins. This is especially true for the user management in the Adminapp.
• If combining multiple persistence systems (e.g. the IAM database and an external system via a custom plugin), minimize called to potentially slow external systems. Typically, not all calls in all plugins need to involve external persistence systems.

Hash Algorithms

Some hash algorithms, such as "scrypt" are expensive by design in order to make brute-force attacks on hash databases unfeasible, i.e. increase the security of the hashed data. On the other hand, choosing an expensive hash algorithm limits the number of request that a system is able to process per time unit. Other hash algorithms, such as "sha256" are pretty fast and therefor easier to bruteforce.

Airlock IAM uses hashes for various use cases. Depending on the use-case a different hash algorithm is suitable.

See selection and parametrization of hash functions for further information and tuning options.

Current Version

New Airlock IAM versions are often bringing additional performance optimizations. Check for the current version.

Example of Dimensioning and Scaling

Assumed Hardware:

• Server with 2 CPUs each with 8 cores at 2.5 GHz.

Assumed Configuration:

• password with scrypt hashes as the first factor
• MTAN as the second factor
• Audit Log signing is switched off
• the DB connection pool has a size of 16 and fits well the performance of the DB server
• the "general indices" mentioned above are created.

Expected Performance:

• 50-90 entire login/logout roundtrips per second

Airlock IAM scales well with the number of CPUs and cores. However CPU threads won't help, since the system is CPU-bound (scrypt). CPU threads are beneficial if a CPU core has to wait for I/O.

For further scaling it is possible to loadbalance multiple Airlock IAM behind Airlock WAF.