You are here

Airlock Login/IAM Performance Tuning

Affects product: 
Airlock IAM
Airlock Login

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

Audit Log

Airlock Login/IAM up to 6.4.x digitally signs audit log messages 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.

To disable audit log signing:

  • Open the file audit-logger/medusa-audit-logger.properties within the instance (e.g. instances/auth/audit-logger/medusa-audit-logger.properties) in an editor.
  • Change the value of property medusa-audit-logger.signature-algorithm to NONE (i.e. medusa-audit-logger.signature-algorithm = NONE).
  • Activate the change: medusa.sh update <instance-name> (e.g. medusa.sh update auth)

    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 built-in 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).

    We recommend the built-in H2 database only for testing purposes and for small production scenarios with some hundreds of users.


    Database Monitoring

    The database as well as the database host have to be monitored to detect unexpected increasing system load, a high proportion of I/O wait or inefficient queries due to missing indexes.

     


    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.

    General Indices

    Airlock IAM versions 6.4 and 6.4.1 define the following additional indices and primary keys in the database schema setup scripts. The database schemas are not updated automatically when updating the Airlock Login/IAM software. The following changes have to be performed manually.

    Changes for all versions of Airlock IAM:

    CREATE INDEX ta_index ON token_assignment (ta_user, ta_token_id);
    CREATE INDEX serial_id_index ON token (serial_id);
    CREATE INDEX token_type_index ON token (type);
    

    Changes for Airlock IAM versions starting with 6.4:

    ALTER TABLE token_assignment ADD CONSTRAINT fk_ta_token_id
          FOREIGN KEY (ta_token_id) REFERENCES token (token_id);
    ALTER TABLE token ADD CONSTRAINT fk_obsoletes_token_id
          FOREIGN KEY (obsoletes_token_id) REFERENCES token (token_id);
    ALTER TABLE token ADD CONSTRAINT fk_activates_token_id
          FOREIGN KEY (activates_token_id) REFERENCES token (token_id);

    Recommended Indices Depending on the Configured Features

    If IAM is used as OAuth2 Authorization Server (AS):

    For MySQL:

    CREATE INDEX generic_data_element_1_idx ON token (generic_data_element_1(40));
    CREATE INDEX generic_data_element_6_idx ON token (generic_data_element_6(40));
    CREATE INDEX generic_data_element_7_idx ON token (generic_data_element_7(40));

    For Oracle/MSSQL/H2:

    CREATE INDEX generic_data_element_1_idx ON token (generic_data_element_1);
    CREATE INDEX generic_data_element_6_idx ON token (generic_data_element_6);
    CREATE INDEX generic_data_element_7_idx ON token (generic_data_element_7);

     

    If Vasco OTP tokens are used (except Vasco Cronto):

    CREATE INDEX obsoletes_token_id_idx ON token (obsoletes_token_id);

     

    If Vasco Cronto is used:

    For MySQL:

    CREATE INDEX generic_data_element_1_idx ON token (generic_data_element_1(40));
    CREATE INDEX generic_data_element_2_idx ON token (generic_data_element_2(40));
    CREATE INDEX generic_data_element_4_idx ON token (generic_data_element_4(40));

    For Oracle/MSSQL/H2:

    CREATE INDEX generic_data_element_1_idx ON token (generic_data_element_1);
    CREATE INDEX generic_data_element_2_idx ON token (generic_data_element_2);
    CREATE INDEX generic_data_element_4_idx ON token (generic_data_element_4);

     

    If "Cronto Engine (Cronto SwissSign)" tokens are used:

    For MySQL:

    CREATE INDEX generic_data_element_1_idx ON token (generic_data_element_1(40));
    CREATE INDEX generic_data_element_3_idx ON token (generic_data_element_3(40));

    For Oracle/MSSQL/H2:

    CREATE INDEX generic_data_element_1_idx ON token (generic_data_element_1);
    CREATE INDEX generic_data_element_3_idx ON token (generic_data_element_3);

    DB Statistics

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

    We strongly recommend configuring the DB system to create new statistics regularly.


    DB Connection Pool

    Connections from Airlock Login/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) and connection pool configuration (e.g. pool size). The Loginapp typically needs more DB connections than the Adminapp.

    As a rule of thumb, the developers of the "Hikari" connection pool recommend limiting the number of connections to twice the number of CPU cores of the DB server plus the number of disk spindles.

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


    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 Login/IAM uses hashes for various use cases. Depending on the use-case a different hash algorithm is suitable.

    We recommend

    • Scrypt for passwords, secret questions and IAK letters
    • SHA-256 for OAuth, Open ID Connect and matrix cards

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


    Current Version

    Often new Airlock Login/IAM versions are bringing additional performance optimizations. Check for the current version. Especially versions 6.3.6 and 6.4.1 are containing valuable improvements for REST calls and token persistence.


    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 Login/IAM behind Airlock WAF.

    Knowledge Base Categories: