The decision to use either configuration contexts or IAM instances is mainly driven by customer requirements and complexity considerations. The following table provides some indications of how different factors should influence the decision to either use configuration contexts or to use IAM instances.
Criteria | User Story | Recommendation |
|---|---|---|
User Persister | The configuration uses multiple different user persisters to manage different user communities. | Maintaining different user persisters for different user communities should be an indicator to investigate the use of different IAM instances instead of configuration contexts. |
Self-Registration | Self-registration functionality becomes more common to manage large user communities while minimizing costs. | The use of self-registration functions is a fairly good indicator for the use of a separate IAM instance and a separate user persister. |
Authentication factors | Multiple different authentication means are used for the same user base. | This type of setup works well without configuration contexts. Contexts may be needed for advanced functionality (e.g. self-services) in combination with client certificate authentication. |
Intranet vs. extranet | The same users may access the same services from intranet and extranet. The requirements on the extranet login differ because an additional authentication step is required. | Configuration contexts are ideal to model this type of setup. |
Look and Feel | A variety of back-end applications needs to be exposed on the internet. User experience demands that the login screens and potentially the self-registration processes should look different depending on the back-end application. | Both configuration contexts and separate IAM instances can support different login screens. The decision which setup is more ideal should be driven by the management of the user persister and not the login screens.  Configuration context-dependent custom Loginapp UIs are not supported in the Loginapp REST UI. |
Authorization | To authorize access to different back-end applications different roles are to be implemented. | Authorization should be implemented using roles. Avoid using configuration contexts for this purpose. |
Complexity | The increasing complexity of an IAM configuration is an increasing security risk because it detracts from the maintainability and comprehensibility of the configuration. | Configuration contexts will likely increase the complexity of a setup and not decrease it. Separate IAM instances may be used to reduce complexity in a configuration. |
Operation / Multiple Tenants | Operational costs are caused by maintaining infrastructure (HW, OS), IAM software, and configuration. Infrastructure costs can be budgeted in the form of housing costs. IAM software will require 2-3 updates every year. Configuration maintenance depends on the number of changes and the complexity of the existing configuration. | Configuration contexts may increase complexity and therefore increase operational costs. Additional IAM instances will increase SW maintenance tasks and therefore increase operational costs. |
License costs | IAM license costs are driven by functionality (included bundles) and the size of an installation (registered users). | Cost optimization depends on the use case. Mixing a large number of customers with limited functionality (few bundles) with a small number of employees with extensive functionality (many bundles) leads to higher costs in a single IAM instance as if the two user communities were split over separate IAM instances. |