Differential Timeouts with like IdPs?

Cantor, Scott cantor.2 at osu.edu
Wed Jan 29 09:31:06 EST 2020


On 1/28/20, 5:03 PM, "users on behalf of Michael Gettes" <users-bounces at shibboleth.net on behalf of gettes at ufl.edu> wrote:

> I would like to be able to have a default config for Idle Timeout  (and maybe more, but this is a start for now) based on a 
> combination of the user (what LDAP group(s) they may be a member of) and the application/SP they are accessing.

It's not currently dynamic, it's a static setting on the authentication beans in general-authn.xml. I suspect I could make it dynamic, but it's a bit close to the release to be making changes like that as it's an invasive change that will have to hit a lot of different spots.

> I am accessing SP-AAL3 and sets my idle timeout to 30M.  This appears to not be possible now???

There isn't such a thing as "idle timeout" in some general sense. There are timeouts on every individual authentication result. Those are currently static. Making them dynamic with a function lookup would provide the ability, though only with complex scripting or Java, to examine the state of a session to decide what the timeout should be.

> But, if I configured IdP-AAL3 to be just like IdP-Home (same keys and crypto for cookies) and SP-AAL3 was
> configured to only use IdP-AAL3 - would I not still get a SSO experience for my users without the
> additional sign-on event?

They'd have to live at the same URL and be the same IdP in every sense that matters.

> If this is not possible right now, what would It take to make this possible?

Code changes.

But I think you're overcomplicating what is in reality a demand to disable SSO. The fact that you're recognizing users won't like it is exactly the point. If user reaction is the key, you don't spend time on an  outmoded concept like session timeout. OSU is constantly doing the same thing, and I tell them the same thing: this is really a problem of shared machines because personal machines should deal with idle timeout by using screen locks.

OTOH, if the user be damned, what you really want is ForceAuthn for that SP, and not to have a timeout at all.

> Thoughts and pontifications appreciated.

Timeout is one of the things I spend a lot of time pontificating about.

-- Scott




More information about the users mailing list