Shibboleth session vs Application session

[Sathish Anickode]

Thanks for your detailed reply. I was thinking of implementing exactly the same steps that you had outlined below to solve our needs. To refresh the user session, I am currently thinking of setting the authentication duration to a longer suration (e.g. 4 hrs) and session timeout to 15 mins. We then need a one page session refresh app that is stateless but accessed periodically from our custom applications while the user is actively using the app. However, I feel exposing an api or a page in the IdP  to touch the user session that can be invoked from our app will be a better solution than creating a single page application. Is it possible to add such a support in IdP?

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Eric Goodman
Sent: Tuesday, December 16, 2014 11:54 AM
To: Shib Users
Subject: RE: Shibboleth session vs Application session

> As I have told you, several times, you are confusing the IdP session, 
> which has nothing to do with any of this, with the login handler 
> duration, which has
> *no* timeout, only a lifetime. As such, there is no timeout to extend. 
> It's a hard cap, however long after the initial use of the login handler.
> 
> -- Scott

A discussion of the distinction Scott calls out here are found at:

	https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthnSession

If you're using Username/Password authentication the page:

	https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthUserPass

Provides an overview of the Login Handler and calls out the "authenticationDuration" value that controls the authentication lifetime.

>I am finding that the IdP user session does not extend the user session 
>timeout, when the user authenticates with App2 after 10 minutes. The 
>documentation states that the user session is reset when the user tries 
>to authenticate with a service provider. But in my test that does not 
>seem to be the case. Is my observation correct or am I missing something?

The second login extends the session timeout, but not the authentication method's lifetime (default 30 minutes). So for your purposes, extending the IdP session is meaningless after 30 minutes overall (not idle time) have elapsed.

If I understand the documentation above correctly, it looks like you could get the behavior you are asking for by setting a long lifetime on the Authentication Method (say 8 hours) and a 15 minute user session on the IdP. If the user is idle (at the IdP) for more than 15 minutes, their authentication validity would expire with their user session. But if they repeatedly re-visit the IdP (by logging into other SPs) within the 15 minute window, their session would be extended for as long as 8 hours.

Note that this means that (a) authentication to ANY application would extend the IdP session and effective authentication lifetime and (b) in reality users would probably still see a username/password prompt every time they visit a new application, since normal usage patterns probably don't have a user logging in to a new app every 10 minutes.

So I think this technically meets what you're asking for, but may not match the behavior you actually want (since activity at the SPs doesn't extend anything, only actual login/authentication events do).
 
--- Eric

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net