Evenly secure configuration for all relevant parts is essential for the overall security level. The following content gives an overview and best practice advices to maintain a high level of data security.
General configuration
Airlock IAM can be configured in many different ways. The configuring entity (usually the integrator) is responsible for creating a secure configuration.
Use the following as a checklist for securing the configuration:
Do not use default passwords or weak passwords in the configuration.
Do not use dummy or test configurations in live environments.
- Dummy- and test-plugins are useful for testing.
- For simplifying testing, mark all configurations done with an easy-to-lookup tag in the comment field (e.g. "TODO"). You may search for them in the Config Editor search panel.
Use SSL/TLS where possible. Failing to do so may result in severe security risks.
Secure IAM with a Content Security Policy (CSP). Failing to do so may result in severe security risks.
Never send the internally used session ticket cookie to the client, i.e., by defining it as a pass-through cookie in the Airlock Gateway.
Always restrict the allowed forward locations in the Loginapp's security settings to the minimum required set of URLs. Failing to do so may result in severe security risks.
When using LDAP or AD Directories, make sure that unauthenticated binds are not possible in the directory and that allow empty passwords is disabled in the IAM configuration unless really wanted (disabled by default).
If emails are sent in HTML mode, all values in HTML should be escaped. This is because variables in HTML emails are not encoded. Examples of such variables are first name, surname, address, email address, or other user context data. If these variables would be filled with HTML-interpretable script, the script could be executed. This makes your system vulnerable to Cross-Site-Scripting (XSS) attacks.
To prevent these XSS attacks, the Send As HTML feature is disabled by default for all plugins that send emails. As an additional safety measure, the Escape Values in HTML property is enabled.
However, some situations may require the explicit use of emails in HTML mode. Note that you should do this only for low-security applications and if it is considered safe! In this context, it is possible to selectively escape specific values that do not have to appear in HTML. The article Escaping HTML values in emails explains how to configure this.
Remove unnecessary plugins from the configuration (especially when developing a configuration based on the demo configuration).
It is strongly recommended and good practice to have the configuration reviewed by an independent security auditor for all critical services.
Use safe defaults in the configuration, e.g., use the DenyingAuthenicator as a fall-back.
Further information and links
The following sections cover the different fields of configuration within IAM more specifically: