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.

 
Notice

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:

 
Risk

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 .
  • 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 and Airlock IAM (no unauthenticated access to the IAM Adminapp)
    • Restrict access as much as possible using specific Gateway filters (white-list filters)
 
Risk

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.
 
Info

Use Airlock Gateway 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:

 
Risk
  • Always use an Airlock Gateway in front of the Loginapp or Loginapp REST API. Never allow direct access from the Internet!
  • Make sure Gateway 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).
 
Risk

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

 
Risk

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

 
Notice

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 such that access from untrusted networks is only possible via Gateway and only to the Loginapp / Loginapp REST API.
 
Info

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

Use the OpenAPI specification and validation to secure the Loginapp REST API.