The following use cases are not recommended but are known to work in controlled setups. Keep in mind the following, when implementing them:
- The configuration context extraction is not independent of the HTTP request's IAM URI (e.g. login page, check-login URL, OAuth end-point, or step-up authentication).
- You must take great care, that IAM is only accessed through entry points (IAM URIs) that support the specific context extraction
- You must ensure that accessing other entry points (IAM URIs) results in a meaningful default context and that IAM works (or fails) securely with that default context.
- Improper usage of configuration context may result in unwanted or insecure IAM setups.
The listed use cases do not work with the Loginapp REST API (and therefore also Loginapp REST UI) because it does not support context retention policies.
Evolving IAM configuration
Before implementing one of the use-cases (or something similar), also consider how the IAM configuration may possibly evolve in the future:
Use-Case | Description / Example | Recommendations / Remarks |
---|---|---|
NU1: Target-Application dependent Configuration | Different configuration settings depend on what target application a user is accessing. Example: separate language settings or string properties for each target application. This only works with the JSP-Loginapp and is no more supported in IAM 8.0 and later. |
Typical Context Extractors for this use case: Forward Location Context Extractor, URL and Forward Location Context Extractor. Both extractors are no more available in IAM 8.0 or later. |
NU2: Parameter-based Context Extraction | The context is determined by inspecting an arbitrary HTTP parameter. Examples:
Support for this use case in the Loginapp REST API (and therefore Loginap REST UI) is very limited. |
Typical Context Extractors for this use-case: Http Parameter Context Extractor. |