Non-recommended use cases – config contexts
9.2.3.2. Non-recommended use-cases for configuration contexts

The following use-cases are not recommended but 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 make sure that accessing other entry points (IAM URIs) results in a meaningful "default context" and that IAM works (or fails) in a secure way with that "default context".
  • ●
    Improper usage of configuration context may result in unwanted or insecure IAM setups.

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 depending on what target application a user is accessing.
Example: separate language settings or string properties for each target application.
  • ●
    Only works as long as the "target application" (IAM internally this is called the "forward URL") is present in the session.
  • ●
    Target application must be known to IAM in the first HTTP request hitting IAM. May fail if the configuration evolves (e.g. use OAuth or SAML to log in at a later point).
  • ●
    Will only work with IAM entry URIs that support the "Location" parameter (e.g. /login or /check-login)
  • ●
    You must define a valid configuration for the "Default Context", i.e. if no target application is known.
Typical Context Extractors for this use-case: "Forward Location Context Extractor", "URL and Forward Location Context Extractor".
NU2:
Parameter-based Context Extraction
The context is determined by inspecting an arbitrary HTTP parameter.
Examples:
  • ●
    Pass a "context"-Parameter in an HTML form or as GET parameter.
  • ●
    Look at an IAM parameter (e.g. username in the login form)
  • ●
    The context can only be determined in HTTP requests that bear the specific HTTP parameter
  • ●
    Either make sure, the HTTP parameter to inspect is present in the first HTTP request hitting IAM and choose the right context retention policy.
  • ●
    Make sure, IAM works as expected (or fails in a safe way) even if the HTTP parameter is missing: users may bookmark pages or otherwise directly access URIs you do not expect.
  • ●
    May fail when the IAM configuration evolves (e.g OAuth or SAML to log in at a later point).
Typical Context Extractors for this use-case: "Http Parameter Context Extractor".