Differential Timeouts with like IdPs?

[Michael Gettes]

Thanks Scott.  This is exactly along the lines I was expecting.  The issue I am really grappling with is federal requirements (contracts) on certain application environments (medical and research computing) where AAL2/3 come into play.  There are some users this impacts, but not all.  I am hoping I can maintain SSO for those who are not impacted and only when they go to use these “protected” apps we adjust the timeouts.  I agree, it was after I posted I fully realized the separate IdP path wouldn’t work and it all has to be the same IdP and only altering timeouts when a qualified user visits an SP triggering the different timeout.  On one hand, I agree with your perspective.  On the other hand, IF this problem could be solved along with some strong recommendations on how to use it then I think this might help all those with these requirements.

Yesterday I spent several hours with InfoSec policy folk going through 800-63 (yet again, you know how I love 800-63 and friends) and other OMB documents and this is the conclusion we all reached.  We can address non web issues with AD GPOs for users and lockout timeouts and so on - but it’s the web context that’s a bit alluding and Shib seems well positioned (with code changes as you suggest) to be able to help solve, if not solve, the issues.

Lastly, on “user be damned” - yes, it’s heading in that direction but still having some amount of “SSO-like experience” so it doesn’t totally suck for the user.  I don’t like the idea of no timeout at always forceAuthn.  Why?  Because administering these higher security environments means I am impacted and that experience would make me retire early.  (And if you want me to retire early - here’s your chance to say “no” :-) ).

I hope this helps explain better perspective and intent.

Thanks again for the consideration AND the continued pontification!  This pontification is how we got to SAML in the first place (can you believe it’s been 20 years?) :-)

/mrg

> On Jan 29, 2020, at 9:31 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
> [External Email]
> 
> 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
> 
> 
> --
> For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=sJ6xIWYx-zLMB3EPkvcnVg&r=wEQWI9G4vDvpfmhpuO6yww&m=WTX-f5lhEZ4b7LL06cbQlCyqcZ-QU9zOQqR0DErFNSk&s=0XjKis1PGT6AP1hFaCdOL5YKzgX_AiLJzhy1YsF2Xkw&e=
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net