unexpected SSO session timeout

[Cantor, Scott]

On 12/16/16, 5:15 PM, "users on behalf of IAM David Bantz" <users-bounces at shibboleth.net on behalf of dabantz at alaska.edu> wrote:

>    My idp V 3.2.1 is expiring SSO sessions more quickly than I thought I had configured in .../conf/idp.properties:
> # Inactivity timeout
> #idp.session.timeout = PT8H 

You have a commented out property but that isn't what the default is. The delivered file is:

# Inactivity timeout
#idp.session.timeout = PT60M

In other words, if you want it to be 8H, you can't comment that out.
    
>    But logins to relying parties challenge for authN within about 3 hours.

With a default 60M timeout on the session, the timeout is not going to be fixed, it's going to depend on how often it gets hit and if you go more than an hour *plus* the sessionSlop setting, without hitting it, it's going to be gone. That's not going to be predictable as a fixed value from the start of the session, it depends on activity.

> (Verified this on a client with single wired network connection with fixed IP, after verifying expected longer-lived SSO
> session on still running V2 IdP).

That just means you maintained enough activity at first to keep the session around and then waited long enough that it wasn't, and that start to finish time was 3 hours. That does not mean the timeout was 3 hours for anybody else.

>    I find this additional reference to idp timeout in session-manager-system.xml

That's set to the same default that we ship it with, and that you changed without actually uncommenting the setting. If you want to change the setting, just don't comment out the property.

> Is that the correct place to extend SSO session lifetime ?  

There is no such thing as SSO session lifetime at all. There is an IdP session *timeout*. Not lifetime. There are the lifetime *and* timeouts on the login methods. All of them combine to produce an outcome.

Given all of the history, I can tell you the outcome at any given point in time that a request happens. At no point is there a fixed result you can predict in advance without constraining the usage pattern in between. Given no access at all after the first time, the lowest of the various settings is going to be the main constraint.

In terms of *maximum*, the main driver is the login method lifetime. There are a variety of ways that can be shortened in any given case. Basically, there's a minimum and a maximum that can be worked out, but any number of possible outcomes in the middle.

-- Scott