Required reading
If you are not familiar with the concept of configuration contexts, read this first: Configuration contexts
Configuration contexts were introduced to support the dynamic adaption of the IAM configuration 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 and maintain. 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:
The general principle for configuration contexts
Configuration contexts are designed to solve simple problems. A change, applied in a configuration context, should be very limited. 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 a complex setup tends to increase operational costs and introduces risks to availability and security. This holds especially true if the design goal is strong segregation of use cases. Configuration contexts have been designed to support closely related setups, strong segregation is much easier enforced with separate Airlock IAM instances.