...
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 unavailablethe request to the IdP (the specifics of which depend on the protocol in use)
the
defaultAuthenticationMethods
property attached to the profile configuration in effect
Localtabgroupexpand | |||
---|---|---|---|
Localtab live |
| ||
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. Localtab live | | active | true
Expand | ||
---|---|---|
| ||
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.
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:
...
If the request calls for forced authentication, or if there are no active AuthenticationResults from a session, go to step 3.
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).
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:
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).
The matching flow is chosen.
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.
Localtabgroupexpand | |||
---|---|---|---|
Localtab live |
| ||
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. Localtab live | | active | true
Expand | |||||
---|---|---|---|---|---|
| |||||
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 As an example, say you wanted to support an SP that's insisting on requesting the authn/authn-comparison.xml
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. |
...