Page Comparison

...

In the vast majority of cases, only a single "top level" method may be enabled (often the MFA method), but for those with very complex requirements to support widely varied mechanisms at the same time, the process is described below, along with the options available to influence the process without writing code. Of course, understanding the process is important for those writing code as well.

Inputs

At a very high level, the following runtime information is captured as input to the process:

• any active session for the client along with any still-valid previous AuthenticationResult objects that may be possible to reuse

• the AuthenticationFlowDescriptor objects for any login flows enabled for use via the idp.authn.flows property and the authenticationFlows property attached to the profile configuration in effect; any flows not included in both sets are considered unavailable

• the request to the IdP (the specifics of which depend on the protocol in use)

• the defaultAuthenticationMethods property attached to the profile configuration in effect

With respect to the request, the chief piece of information extracted is anything the request specifies to limit or control the login method used. Out of the box, this is only supported for SAML 2.0 requests (the <RequestedAuthnContext> element), but the information is extracted in a portable form ahead of this step, so any protocol with this feature can be supported equally and uniformly. For example, the OIDC OP extension supports a similar feature.

...

The simplest steps performed during this pipeline are a straightforward filtering of the possible login flows based on high-level requirements. This fiiltering includes:

• eliminating flows that don't support "passive" use if the request requires this (corresponding to the IsPassive flag in SAML 2)

• eliminating flows that don't support "forced authentication" if the request requires this (corresponding to the ForceAuthn flag in SAML 2)

• eliminating flows that require a browser client if the request is from a non-browser client (e.g., the ECP profile in SAML 2)

Flow Selection

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.

...

Apart from that, one of three cases applies:

• the request contained no requirements as to which login flow to use

• the request contained specific requirements as to which login flow to use

• a login flow explicitly asked that another login flow be tried (inter-flow signaling, mentioned under AuthenticationConfiguration, Advanced Features)

The first two general cases are described below.

...

When the request to the IdP doesn't explicitly have method requirements, the selection process proceeds as follows:

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.

This is the basic/simple case and requires no special attention.

...

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.

...

There are beans predefined and registered for each of the inexact matching types possible to support the basic mechanics of the "better", "minimum", and "maximum" operators. The latter two cases are defaulted internally to allow degenerate support by treating the request as equivalent to "exact" (because they're inclusive of the value supplied in the request), but "better" matching won't succeed without explicit comparison rules added since it's non-inclusive.

authn/authn-comparison.xml

<util:map id="shibboleth.AuthnComparisonRules">

	<entry key-ref="shibboleth.SAMLACClassRefMinimum">
		<bean parent="shibboleth.InexactMatchFactory">
			<property name="matchingRules">
				<map>
					<entry key="urn:oasis:names:tc:SAML:2.0:ac:classes:Password">
						<list>
							<value>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</value>
							<value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</value>
							<value>urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken</value>
						</list>
					</entry>
				</map>
			</property>
		</bean>
	</entry>

</util:map>

Other cases are similar. The beans shibboleth.SAMLACClassRefMinimum, shibboleth.SAMLACClassRefMaximum, and shibboleth.SAMLACClassRefBetter are predefined as keys you can use for the three operators, and the example above illustrates the sort of bean you'd define as a map value for the rules.

...