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

Internally, the AuthenticationFlowDescriptor objects are maintained in the order they're declared in the list of beans in authn/general-authn.xml. This means that absent other influences, the general order flows will be tried can be controlled with that list.

Internally, the AuthenticationFlowDescriptor objects are maintained in an order driven by the idp.authn.<method>.order properties in authn/authn.properties. Lower-numbered flows are sorted ahead of higher.

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.

...

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.

The authn/authn-comparison.xml file includes an example of how to define such rules. Each bean contains a property to set with a map of values that might be requested and a corresponding list of values that should satisfy the request.

The latest shipped version of the authn/authn-comparison.xml file has been simplified and no longer contains a lot of extraneous content to support this edge case. The commented map bean named shibboleth.AuthnComparisonRules must be uncommented and an overridden matching rule added to the map to supply behavior for one of the operators to change its behavior.

The map entry key determines which type of object and which matching operator to configure behavior for. The map entry value is a bean that inherits from shibboleth.InexactMatchFactory that provides the ruleset.

The latter bean in turn contains a matchingRules property that is itself a map. The keys of this map are the values that might be requested, while the values of the map entries are the values that should satisfy the request.

As an example, say you wanted to support an SP that's insisting on requesting the <AuthnContextClassRef> value of urn:oasis:names:tc:SAML:2.0:ac:classes:Password and an operator of "minimum", and you have a couple of supported values that you want to teach the IdP are "as good as" this value. This is what that looks like:

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

Ignoring Requested Values

...