RE: [security-services] Use Cases

["Beach, Michael C" <michael.c.beach@BOEING.COM>]

Agree with your comments, I think.  A clarification - the ForceAuthn would only apply for the session for which the SP makes the ForceAuthn request, not all sessions.

Right?

Mike

-----Original Message-----
From: Greg Whitehead [mailto:grw@trustgenix.com]
Sent: Tuesday, November 25, 2003 11:56 AM
To: Beach, Michael C
Cc: John Kemp; security-services@lists.oasis-open.org
Subject: Re: [security-services] Use Cases



On Tuesday, November 25, 2003, at 01:29 PM, Beach, Michael C wrote:

> John, yes that does make sense.
>
> As a result of today's telecon about reducing the scope of this item, I 
> was considering the implications of session authorities not addressing 
> idle timeout.
>
> Givens:
> - We have service providers that have some sort of mandatory timeout 
> restriction (preferably idle, but we don't have that today)
> - Service providers typically have need to create local sessions 
> (either legacy or to streamline interaction)
>
> Consideration:
> Multiple sessions without global idle timeout monitoring could be a 
> reasonable compromise.
>
> I still see need for some kind of independent management of sessions 
> for collections of SPs, where each collection is made up of 1 or more 
> SPs with similar security policy.  Then if we could at least provide a 
> mechanism for a service provider to signal a session termination or 
> re-authentication required?  The issue I have today is SPs that want to 
> do some kind of timeout (or session logout) and force a 
> re-authentication for their session only.  Because we have an SSO 
> implementation (single global session), a re-authentication event is 
> handled automatically by the authentication authority without user 
> interaction.  The SP considers that a security flaw, potentially to the 
> point that the SP will not participate in our enterprise SSO 
> initiative.  If the SP had a means to control "their" session, I could 
> likely sell the compromise.

The Liberty AuthnRequest has a flag called ForceAuthn that can be used 
by an SP to force the user to be re-authenticated even if the IdP has an 
active session with him/her. In the context of this session discussion, 
I can imagine a slightly different mechanism being useful, where the SP 
could signal the 'freshness' of authentication that it finds acceptable. 
In other words, if it has been >N seconds since the user was last 
authenticated in the current session, re-authenticate him. This would 
perform better in a multi-SP scenario where the user remains idle at two 
different SPs for some period of time greater than the idle timeout and 
then revisits them both in a short time interval.

> The clearly stated business scenario does call for global idle time 
> tracking, but something is better than nothing.

Not having global idle time tracking impacts the user experience, I 
guess, but at least it doesn't compromise security. Having each SP track 
idle time independently may lead to sessions being expired sooner than 
they otherwise would (but not later).

-Greg