Differential Timeouts with like IdPs?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Differential Timeouts with like IdPs?

Gettes, Michael
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.

Scenario:

I access an SP-X via my IdP-Home and I receive a default session of 10H and an idle timeout of 10H.
I then go to access SP-AAL3 and because I am a user in ldap group AAL3 my IdP-Home sees
I am accessing SP-AAL3 and sets my idle timeout to 30M.  This appears to not be possible now???

I realize I could have SP-AAL3 be bound to another IdP-AAL3 like my IdP-Home but with different
idle timeout config of 30M but this would involve an additional SSO sign-on - which would annoy my users.  
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?  Would this get me an idle timeout to 30M going forward for all interactions with
SP-AAL3 and 10H for all SPs associated with IdP-Home?  Has anyone done this?

I am trying to keep the scenario as simple as possible.  If this is not possible right now, what would
It take to make this possible?

Thoughts and pontifications appreciated.

/mrg

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Differential Timeouts with like IdPs?

Ray Bon
Michael,

Your SP session should be managed from within the SP.

What would happen to your SP-X session when user accessed SP-AAL3?

Ray

On Tue, 2020-01-28 at 17:02 -0500, Michael Gettes 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.

Scenario:

I access an SP-X via my IdP-Home and I receive a default session of 10H and an idle timeout of 10H.
I then go to access SP-AAL3 and because I am a user in ldap group AAL3 my IdP-Home sees
I am accessing SP-AAL3 and sets my idle timeout to 30M.  This appears to not be possible now???

I realize I could have SP-AAL3 be bound to another IdP-AAL3 like my IdP-Home but with different
idle timeout config of 30M but this would involve an additional SSO sign-on - which would annoy my users.  
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?  Would this get me an idle timeout to 30M going forward for all interactions with
SP-AAL3 and 10H for all SPs associated with IdP-Home?  Has anyone done this?

I am trying to keep the scenario as simple as possible.  If this is not possible right now, what would
It take to make this possible?

Thoughts and pontifications appreciated.

/mrg

-- 
Ray Bon
Programmer Analyst
Development Services, University Systems
2507218831 | CLE 019 | [hidden email]

I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations.

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Differential Timeouts with like IdPs?

Peter Schober
In reply to this post by Gettes, Michael
* Michael Gettes <[hidden email]> [2020-01-28 23:03]:
> I access an SP-X via my IdP-Home and I receive a default session of 10H and an idle timeout of 10H.
> I then go to access SP-AAL3 and because I am a user in ldap group AAL3 my IdP-Home sees
> I am accessing SP-AAL3 and sets my idle timeout to 30M.  This appears to not be possible now???

I think Ray's reply hints at keeping SP-AA3's sessions and business
within that SP, and not trying to messing up the subject's IDP session
based on a singular SP's opinion.
The SP has ways of finding out when the initial authn happened at the
IDP (included in the IDP's last response that itself may have been
based on SSO, not authn) so if the SP cared it could always decide to
treat not accept that login, e.g. by sending the IDP another authn
request, this time with forced authn set, or whatever.

> I realize I could have SP-AAL3 be bound to another IdP-AAL3 like my
> IdP-Home but with different idle timeout config of 30M but this
> would involve an additional SSO sign-on - which would annoy my
> users.  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?  Would this get me an idle
> timeout to 30M going forward for all interactions with SP-AAL3 and
> 10H for all SPs associated with IdP-Home?  Has anyone done this?

You mean restoring an IDP session using client-side state across
completely different IDPs (hostname, endpoints, entityID)?
The browser wouldn't share any of its state with another host?

> I am trying to keep the scenario as simple as possible.  If this is
> not possible right now, what would It take to make this possible?

I think going back a step and looking at what made you consider
shortening the IDP's session based on the subject being in a specific
group and having accessed a specific SP would be helpful.
(That last part sounds a bit arbitrary to me.)

Best,
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Differential Timeouts with like IdPs?

Cantor, Scott E.
In reply to this post by Gettes, Michael
On 1/28/20, 5:03 PM, "users on behalf of Michael Gettes" <[hidden email] on behalf of [hidden email]> 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://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Differential Timeouts with like IdPs?

Gettes, Michael
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 <[hidden email]> wrote:
>
> [External Email]
>
> On 1/28/20, 5:03 PM, "users on behalf of Michael Gettes" <[hidden email] on behalf of [hidden email]> 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 [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Differential Timeouts with like IdPs?

Cantor, Scott E.
On 1/29/20, 10:54 AM, "users on behalf of Michael Gettes" <[hidden email] on behalf of [hidden email]> wrote:

> 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.

Screen saver locks prevent all application access, not just web or non-web, so I'm not sure why it's one or the other. It's the shared machine case where the problems come up, in which case it's best to talk about *that* problem, and not the general one.

Anyway, the way to get it implemented is filing an RFE for it. It's really too big a change for this version this late, so it needs to get tracked so it doesn't get forgotten.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Differential Timeouts with like IdPs?

Gettes, Michael
Scott,

Thank you so much for the response and consideration.  RFE filed as requested.

/mrg

> On Jan 29, 2020, at 11:05 AM, Cantor, Scott <[hidden email]> wrote:
>
> [External Email]
>
> On 1/29/20, 10:54 AM, "users on behalf of Michael Gettes" <[hidden email] on behalf of [hidden email]> wrote:
>
>> 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.
>
> Screen saver locks prevent all application access, not just web or non-web, so I'm not sure why it's one or the other. It's the shared machine case where the problems come up, in which case it's best to talk about *that* problem, and not the general one.
>
> Anyway, the way to get it implemented is filing an RFE for it. It's really too big a change for this version this late, so it needs to get tracked so it doesn't get forgotten.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwIGaQ&c=sJ6xIWYx-zLMB3EPkvcnVg&r=wEQWI9G4vDvpfmhpuO6yww&m=m_5RGWmjccC_ZV8_QAlLsFIw56--f-6sui8UxSlkw24&s=IGXiYf0THh6RwbqzgSUht3i4hm_ciCNApHMO4MODJgg&e=
> To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]