Page Comparison

...

An IdP session is created by default (idp.session.enabled=true) upon a successful authentication event. The IdP session uses a sliding window expiration policy that is updated under one of two conditions:

1. An existing authentication result stored in the session is used to satisfy security demands made by an SP.

2. A new authentication result is created from a successful user authentication event in order to satisfy security demands made by an SP. The new result is also stored in the session.

Thus the IdP session tracks all authentication events that occur during the lifetime of the session, represented by objects of type AuthenticationResult. When the idp.session.trackSPSessionsflagtrackSPSessions flag is enabled, the IdP session also tracks successful requests to access SPs, represented by objects of the base interface SPSession; this facility is required to support single logout.

The IdP session stores each AuthenticationResult keyed on the ID of the login flow that handles the authentication process. The consequence of this design is that a subsequent invocation of the same login flow, for example in response to a forced authentication request, would overwrite a previous result of the same flow. Results stored in the IdP session are themselves subject to expiration by a sliding window up to an absolute limit. If an SP makes a request to the IdP and there is no active authentication result that satisfies the security demands of the SP, the user is forced to reauthenticate.

(A deeper dive into the internals of this design can be found in the Sessions topic.)

Address Binding

IdP sessions are by default bound to an "address" in order to prevent trivial session takeover simply through session cookie exposure. This can be disabled via the Idp.session.consistentAddress property or relaxed in various arbitrary ways through the idp.session.consistentAddressCondition extension point. It is deeply ill-advised to simply disable this checking entirely and it is deeply unsafe to operate networks that hide a plethora of clients behind a single address.

The latter extension point relies on supplying a BiPredicate (a condition that takes two inputs). The first parameter is the address string to which the session is already bound, and the second parameter is the address string that is being tested/evaluated for “equivalence” with the first parameter. That is, the default implementation of this simply compares the two strings for equality.

One existing implementation of this feature is the IPRangeBiPredicate class, which is configured with a number of IPRange objects, and will consider the two input strings “equivalent” if they both fall into one of the supplied ranges.

The session address binding layer supports simultaneous binding of sessions to both IPv4 and IPv6 addresses so clients may use both types and float between them.

...

In many cases an SSO deployment must satisfy policy requirements around how frequently users must reauthenticate. There are three properties that generally determine authentication frequency:

1. idp.session.timeout (default PT60M)

2. idp.authn.defaultLifetime (default PT60M)

3. idp.authn.defaultTimeout (default PT30M)

Under the default configuration, user authentication occurs hourly except in cases where the IdP session (and thus any contained authentication result) is idle for more than 30 minutes. Note that some authentication methods may be non-interactive such that users don't actually have to explicitly provide credentials (IPAddress, X509Internal), but an authentication event is nonetheless occurring hourly under the default configuration.

...