Best practices - Config contexts and context retention
9.2.3. Best practices - Configuration contexts and context retention policy

Required Reading

If you are not familiar with the concept of configuration contexts, read this first: 9.2. Context dependent configuration

The configuration context design was introduced to support dynamic adaption of the configuration of an IAM instance during request evaluation.

Configuration contexts are very powerful and flexible in that they can be used to meet complex requirements. There is however a risk, because overusing configuration contexts may render configurations very complex and difficult to understand. When planning to use configuration contexts it is more important to focus on long term maintenance of the configuration and not only the initial setup. IAM setups have a tendency to grow over time and it may make sense to revisit design choices from time to time to assess if they are still ideal to operate the IAM.

This content has been written to support customers in assessing if their use of configuration contexts is in line with recommended best practices for configuration contexts. The following general principle summarizes the most important points on how to use configuration contexts:

General Principle for Configuration Contexts

Configuration contexts are designed to solve simple problems. A change, applied in a configuration context, should be very limited. Ideally, it should only affect a single plug-in configuration. In this manner configuration contexts are easily understood and easily maintained.

While there is no technical limitation that would prevent the implementation of complex scenarios by using configuration contexts, this is not a recommended practice due to the downsides of such an approach. Maintaining such a complex setup tends to increase operational costs and introduces risks to availability and security. This holds especially true if the design goal is a strong segregation of use cases. Configurations contexts have been designed to support closely related setups, strong segregation is much easier enforced with separate Airlock IAM instances.