Separation of IAM modules

Some features of IAM have been especially built to be used from untrusted environments, some have been built to be used from "internal networks" only.

Use sandboxing to separate modules.

See: Sandboxing with profiles

Access to Adminapp, Adminapp REST API, and Transaction Approval REST API

Consider the following tips regarding access to the IAM Adminapp, Adminapp REST API, and Transaction Approval REST API:

Do not expose the IAM Adminapp / Adminapp REST API or the Transaction Approval to untrusted environments.

  • The IAM Adminapp provides many critical features and should be used from trusted environments only.
  • Access to the IAM Adminapp should be protected by Airlock Gateway (WAF) .
  • If still allowing access to the IAM Adminapp from an untrusted environment, at your own risk, secure it as follows:
    • Use upfront authentication using the Airlock Gateway (WAF) and Airlock IAM (no unauthenticated access to the IAM Adminapp)
    • Restrict access as much as possible using specific Gateway (WAF) filters (white-list filters)

Avoid Privilege Escalation in Adminapp.

  • Administrators with the privilege "Edit Administrator" may give administrator rights to other admin users. Use the privilege with care.
  • Administrators with the privilege "Apply Configuration" may apply configuration changes. Because administrator access control is also part of the configuration, an administrator with this privilege can possibly gain all possible administrator rights. Use the privilege with care.

Use Airlock Gateway (WAF) to protect the interfaces also for internal access.

Access to Loginapp and Loginapp REST API

The IAM Loginapp as well as the Loginapp REST API are designed to be used from untrusted environments. The hints below help in maximizing security for these critical services:

  • Always use an Airlock Gateway (WAF) in front of the Loginapp or Loginapp REST API. Never allow direct access from the Internet!
  • Make sure Gateway (WAF) filters are in "blocking mode" and restricted to the actual usage of the Loginapp / Loginapp REST API (e.g. do not enable SAML allow rules if SAML is not used).

Use HTTPS (SSL/TLS) to access the Loginapp / Loginapp REST API.

Never embed the login form in a page delivered to the browser via HTTP (the client may not verify where secret credentials are sent to).

To better separate the Loginapp / Loginapp REST API from the other IAM modules (Adminapp, ...) use Sandboxing with profiles:

  • Use one profile for the Loginapp / Loginapp REST API
  • Use another profile for all internal services (Adminapp, Transaction Approval, Service Container)
  • Configure OS, network infrastructure, and Airlock Gateway (WAF) such that access from untrusted networks is only possible via Gateway (WAF) and only to the Loginapp / Loginapp REST API.

Make use of Airlock Gateway (WAF) staging techniques to regularly update Airlock IAM mappings to the newest version.

Use the OpenAPI specification to secure the Loginapp REST API.