Page Comparison

...

• 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.

In the event that nothing is specified in the request, the defaultAuthenticationMethods property is essentially a pseudo-requirement that will be imposed automatically, as if the request specified that an exact match to one of the specified custom Principals is required. In SAML terms, a profile configuration such as this:

...

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.

...

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.

<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>

...