Comparison – configuration contexts and IAM instances
9.2.3.4. Comparison of configuration context and IAM instances

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.
Authenticators
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 17.3. Loginapp REST UI. The Loginapp REST UI is available as of IAM 7.1 and will replace the Servlet/JSP-based Loginapp in a later release.

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