different IDP session timeouts for different SPs?

[Flannery, Sean]

That makes sense, Scott.  Thank you.

________________________________________
From: users-bounces at shibboleth.net <users-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Sent: Wednesday, February 11, 2015 12:11 PM
To: Shib Users
Subject: Re: different IDP session timeouts for different SPs?

On 2/11/15, 6:05 PM, "Flannery, Sean" <sean.flannery at jwt.com> wrote:


>
>I think from the documentation this is not possible, but I wanted to
>verify: we have a request from one SP, that protects more sensitive data,
>to enforce a different session timeout at the IDP level, i.e. when that
>SP forwards users to the IDP it only respects sessions that started
>within the last 59 minutes, versus all the other SPs that have the
>default of 8 hours.  From what I'm seeing in the documentation, there is
>just one IDP session for all requests.

Yes, but the IdP session has zero relevance to an SP. If anything, you
might care about how long ago authentication happened, but that's got
nothing to do with the IdP session, that's tracked at the method level. An
IdP session could last a year, but that doesn't mean anything other than
the user never went long enough between contact to let it time out.

>If that's correct, I'm supposing the best practice here is for this
>special SP to have the forceAuth flag set to true and apply its own
>sessions for only 1 hour, i.e. this SP is not part of the normal SSO
>contract since it considers itself special?  Does that sound right?

More or less, yes. If you care when authentication actually happened, you
look at the AuthenticationInstant. ForceAuthn can be a factor in how you
react to that, but you don't want to overuse it. It would be better to
just request, check the gap, and then repeat if necessary with ForceAuthn.

-- Scott

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