Page Comparison

...

• any active session for the client along with any still-valid previous AuthenticationResult objects for 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.

With respect to the request, the chief piece of information extracted is anything the request specifies to limit or control the login method used. At present, 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.

...

The heart of the process is a Java bean step that picks either a pre-existing AuthenticationResult or a login subflow to attempt to fulfull the request. This is where a lot of complex logic is embedded, and in principle could be replaced with an entirely different algorithm without impacting the rest of the system.

One of the things this bean step does is prevent the same methods from being attempted multiple times in a loop by tracking the ones that have been tried already. This can be cirumvented in exceptional cases, but when it's allowed to just "do its thing", the selection bean will eventually try each flow in arbitrary order until one succeeds or all have failed.

...

1. If the request doesn't call for forced authentication, then one of the active AuthenticationResults from a session will be reused if the subflow that produced it is enabled for the request (SSO).
2. Otherwise, one of the enabled and unattempted subflows is chosen and attempted, based on the order of declaration in authn/general-authn.xml.
3. If no unattempted flows remain, authentication fails.

...

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 they're declared) 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.

...