Recommended use cases for configuration contexts

The following use cases are good examples of what configuration contexts were designed for.

  • Common properties of recommended use cases
  • The configuration context can be extracted from every HTTP request (and not selected requests).
  • Context extraction should result in the same context for all URIs within an IAM instance (e.g. login page, check-login URL, OAuth endpoints, etc.). Exception: Use-Case marked with *.
  • Very similar configuration for each configuration context.

Use case

Description / Example

Recommendations / Remarks

RU1:

Internal/External Access

Employees access the same protected applications/services internally ("internal access") and from the internet ("external access").

Internal access requires single-factor authentication but external access requires strong authentication.

  • Determine configuration context based on Client IP range, Airlock Gateway (WAF) Virtual Host, or Gateway (WAF) mapping.
  • Recommended if the configuration for internal and external access is very close, i.e., most of the configuration is shared for both situations.
  • Not recommended if the set of users with internal access and the set of users with external access are distinct.

Context Extractors for this use-case: URL Context Extractor, IP Address Context Extractor.

RU2:

Multiple Similar Tenants

IAM is used for multiple tenants that are very similar. Tenants e.g. only differ in the name of the user table (or directory tree).

  • Multi-tenant setups are typically implemented using multiple IAM instances. Using configuration contexts is a simpler alternative with limited tenant separation (common user management, common log files, same version, same operation hours, etc.). It may be the right choice if tenants are very similar in configuration and all users are managed by the same administrators.
  • Not recommended if using different UIs (Loginapp page layouts).

Context Extractors for this use-case: URL Context Extractor.

RU3:

Client-Certificate (X.509) dependent Configuration

Users are authenticated using client certificates (X.509) used in the TLS handshake and the configuration is slightly different depending on the certificate.

Examples:

  • Based on the certificate issuer or the organization attribute of the subject, the user's profile is loaded from a different database table (or directory tree).
  • Users not accessing using a client certificate must use a 2nd factor and have other token self-services available as users accessing with a client certificate.
  • Easiest to understand, if client certificate authentication is the only way users are authenticated (this is for example guaranteed if the Airlock Gateway (WAF) virtual host or mapping strictly requires a client certificate).
  • Works in combination with alternative authentication methods, but leads to a more complex configuration.
  • Be careful when using publicly available IAM features (e.g. self-registration, logout page) accessible without a client certificate.

Context Extractors for this use case: Client Certificate Context Extractor

RU4:

Special Settings for a single IAM URL*

A single IAM page requires slightly different settings than all others.

  • Only works, if the special settings only affect the one page or URL.
  • May be extended to a few pages.
  • Limited or no support in Loginapp REST API/UI: context cannot be changed within an IAM flow.

Context Extractors for this use-case: URL Context Extractor, Http Parameter Context Extractor.

RU5:

Testing/Demoing

Try out or demonstrate different variants of a feature while keeping most of the configuration constant. For example, different features may be selected by URL and can be shown/tested without configuration change or just by changing the context.

  • Works best with configuration differences that have only a very limited scope.

Context Extractors for this use-case: URL Context Extractor, Static Context Extractor.

Combined Use-Cases

Use cases may be combined using extractors that process multiple other context extractors.

Example: Evaluate both the domain (multiple tenants) and the client IP address (internal/external access) to determine the context.

Example: Evaluate first the domain to set and use a configuration context. If the domain does not determine the configuration context, evaluate the client IP address to determine a configuration context.

  • If concatenating configuration contexts: this is only feasible with very few different extractors as you may have to define a configuration value for all combinations.
  • See recommendations and remarks in the nested context extractor plugins.

Context Extractors for this use-case: Combining Context Extractor, Concatenating Context Extractor.