Context retention recommendations

The following information only applies to the JSP-Loginapp.

The Loginapp REST API does not support context retention policies and it does not allow a context to change during a session and especially not during a flow.

One of the characteristics of configuration contexts is their ability to be changed during an active user session. This ability is controlled by the context retention policy that allows a context to switch with every request, to be determined once for the entire session, or to switch from the default context to a target context exactly once during a session.

Context retention policies are based on session, request, and a mixed case that allows exactly one switch.

The following is the general principle of using context retention policies:

General principle for context retention policies

  • SESSION: The configuration context is determined right at the start of the session and it never changes during this session. This is the most secure method is to determine the configuration context.
  • REQUEST_ONLY_SWITCH_IF_NOT_DEFAULT: The configuration context is set to default context and it may switch to another configuration context exactly once.
  • REQUEST: Evaluates and sets the configuration context for every request.

Recommendations for the example use-cases

Use-Case

Context Retention Policy Recommendation

RU1 and RU2

In both use cases, the configuration context can be determined with every single HTTP request and it will always lead to the same result. Therefore every retention policy would work correctly.

It is recommended to use "SESSION" in this case since this guarantees that the context never changes during a session (even if the above assumption about being able to determine the context with every HTTP request is wrong).

RU3

If client certificates are the only authentication method, choose "SESSION" for the same reason as above.

If combining client certificates with another 2nd factor, choose REQUEST_ONLY_SWITCH_IF_NOT_DEFAULT as the retention policy. Configure the 2nd factor using the default context and the client certificate authentication using a non-default context (e.g. "cert"). If client certificate validation fails (e.g. because a smart card or USB stick) is not present, the user may still switch to the other 2nd factor. As soon as the certificate authentication succeeded, the configuration context "cert" is set and kept for the rest of the session.

RU4

Use policy REQUEST because you want to use the context just for one (or a few) requests and then switch back to the default context.

RU5

Depending on how you use context extraction, all context retention policies may make sense. To keep things simple, use SESSION and then logout and re-login in to test or demonstrate a feature using a different configuration context.

NU1

Use policy SESSION if you can guarantee that the target application is always defined in IAM with the first HTTP request.

Otherwise use REQUEST_ONLY_SWITCH_IF_NOT_DEFAULT: use with care as the configuration context will switch after the first HTTP request hitting IAM.

NU2

Use policy SESSION if you can guarantee that the inspected HTTP parameter is always present first HTTP request.

Otherwise use REQUEST_ONLY_SWITCH_IF_NOT_DEFAULT: use with care as the configuration context will switch after the first HTTP request hits IAM.