Sandboxing is the process by which components of Airlock IAM can be separated from other components or resources. With profiles, sandboxing can be applied to/between web application modules such as Loginapp and Adminapp.
Why use sandboxing?
Depending on your set-up and configuration, it may be the case that Loginapp cannot access some information managed by Adminapp. From a security perspective it makes sense to separate the more exposed components from the internal privileged components. This separation can occur on different levels.
- By default, the web applications are separated by means of class-loader isolation. This is typical for Java web application servers, such as the Tomcat server used in Airlock IAM.
- The "profiles" feature of Airlock IAM allows different sets of web applications to run in separate processes.
- Processes benefit from operating-system-provided security features such as memory protection.
- You may use separate sensitive value stores with IAM, thereby keeping secrets isolated from more exposed applications.
- When using separate Docker containers or virtual machines to run each process, the additional separation strengthens the protection further.
- One more possible step is to not share the configuration directory at all. Note that this virtually results in Adminapp and Loginapp being in separate instances. Since the applications don't know about each other, some features may no longer work, including but not limited to activation of other applications from the Config Editor and the log viewer.
Default behavior without profiles
When no profile is specified, all modules enabled in instance.properties are launched in the same process. This is described as Level 1 in the description above.
Which modules are enabled is defined by the iam.modules property in the instance.properties configuration file. See: Application parameters