ForceAuthn

SAML includes an optional feature during login requests called ForceAuthn that acts as a signal to the Identity Provider to require some form of user interaction during the course of handling the request, overriding the usual implicit assumption that it's acceptable to reuse authentication state from an earlier request (i.e., Single Sign-On).

Aside from just explicitly not wanting Single Sign-On, a more subtle consideration for some applications is an inactivity timeout. Normally this is not something applications can control because they don't control the behavior of the IdP, whose timeout acts as an implicit lower bound on the value an application can actually enforce. SAML's design makes coupling these timeouts impractical, or at the very least outside the scope of the standard, so the most direct way to achieve an effective timeout policy at an SP that is shorter than that of the particular IdP(s) used is to opt-out of SSO altogether.

In any event, use of this feature when using the Shibboleth SP has two components:

• Including the ForceAuthn flag in requests.

• Enforcing its use while processing assertions.

The first is obvious, but the second is required because most SPs don't sign their requests and even if they did, the Shibboleth SP does not implement request/response correlation such that the signature would matter.

Including the flag in requests can be accomplished in a variety of different static and dynamic ways, because it's a content setting that can be applied via many different mechanisms. It can be statically applied using an Apache command (ShibRequestSetting forceAuthn true) or including the forceAuthn="true" property in the RequestMapper when IIS is used. It can also be applied dynamically via a forceAuthn parameter during redirections into the SP's SessionInitiator handler(s).

The second half of the process is something the SP supports at a global "application" level by adding a maxTimeSinceAuthn property to the <Sessions> element in the configuration, which is measured in seconds. This is enforced automatically, but is again global. For more dynamic content-driven scenarios, it's left to applications to enforce this in code (to which end the authentication timestamp is provided to applications via the "Shib-Authentication-Instant" variable).