Current File(s): conf/, conf/authn/general-authn.xml

Format: Properties, Native Spring


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. When the idp.session.trackSPSessions flag is enabled, the IdP session also tracks successful requests to access SPs; this facility is required to support single logout. The IdP session stores authentication results keyed on the ID of the authentication flow that drives the authentication process. The consequence of this design is that a subsequent invocation of the same authentication flow, for example in response to a forced authentication request, would overwrite a previous result of the same flow. Authentication 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.

Security Policy Implications of Session Timeouts

In many cases an SSO deployment must satisfy security 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 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.

Simple Security Policy Example

An example may be helpful in further clarifying how session configuration defines security policy around user authentication. Suppose a deployer wants to implement the following security policy:

  • Users must authenticate at least once daily.
  • An IdP session may remain idle at most for 60 minutes.
# IDP session must be at _least_ as long as authn result lifetime
# Authentication results live for at most 24 hours
# Authentication results may be idle for at most 60 minutes

Advanced Security Policy Example

In some cases it may be permissible to allow some authentication methods to have longer lifetimes than others; for example, an authentication result produced by a hardware token may be valid for a day whereas that of a password credential is valid for an hour. These policies are accommodated by defining a conservative idp.authn.defaultLifetime and more liberal periods for specific authentication methods. A hypothetical security policy follows with the configuration required to implement it.

  • Users must authenticate every hour using a password credential
  • Users must authenticate daily using a hardware token containing an X.509 certificate
  • An IdP session may be idle for at most 60 minutes under any circumstances
 # IDP session must be at _least_ as long as longest authn result lifetime
# Conservative default authentication result lifetime is 60 minutes
# Defines idle time on authentication results. Not overridden per authn method in this case.
    <util:list id="shibboleth.AvailableAuthenticationFlows">
        <bean id="authn/Password" parent="shibboleth.AuthenticationFlow"
                p:forcedAuthenticationSupported="true" />

        <bean id="authn/X509" parent="shibboleth.AuthenticationFlow"
            <property name="supportedPrincipals">
                    <bean parent="shibboleth.SAML2AuthnContextClassRef"
                        c:classRef="" />
                    <bean parent="shibboleth.SAML2AuthnContextClassRef"
                        c:classRef="" />