Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The heart of the process is a step that picks either a pre-existing AuthenticationResult to reuse (SSO), or a login flow to attempt to fulfull the request. This is where a lot of complex logic is embedded.

...

  1. If the request doesn't call for forced authentication, then one of the active AuthenticationResults from a session will be reused if the login flow that produced it is enabled for the request (SSO).
  2. Otherwise, one of the enabled and unattempted login flows is chosen and attempted, based on the order of priority as discussed earlier.
  3. If no unattempted flows remain, authentication fails.

...

When the request to the IdP does have explicit method requirements, or a defaultAuthenticationMethods property is set on the applicable profile configuration, then the selection process is as follows:

  1. If the request calls for forced authentication, or if there are no active AuthenticationResults from a session, go to step 3.
  2. If the idp.authn.favorSSO property is true, then the collection of active AuthenticationResults is searched for a result that matches the request's requirements (SSO).
  3. The request's requirements are examined in order so that its precedence rules are applied, and the collection of enabled and unattempted flows is searched (in the order of priority) for a match to the requirement being examined. Assuming a match is found, one of the following applies:
    1. The collection of active AuthenticationResults from a session is searched for a result from that flow, and the result is further checked to determine if it matches the request requirement. If so, it is reused (SSO).
    2. The matching flow is chosen.
  4. If no unattempted flows that match any of the requirements remain, authentication fails.

A subtle point: login flows may claim to support a variety of requirements but an AuthenticationResult is only reused if that result itself supports a particular requirement. As a concrete example, a single flow might handle both password and multi-factor authentication but generate results specific to one type or the other. Alternatively, separate flows might be used for the two. The selection process handles either case.

...

As noted, exact matching is automatic; this applies when a SAML 2.0 request specifies "exact" matching in anĀ <RequestedAuthnContext> element, or if nothing is requested but the profile configuration includes the defaultAuthenticationMethod property.

...