Re: [security-services] Use Cases

[Greg Whitehead <grw@trustgenix.com>]

Right.

On Tuesday, November 25, 2003, at 02:26 PM, Beach, Michael C wrote:

> 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
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to http://www.oasis-
> open.org/apps/org/workgroup/security-
> services/members/leave_workgroup.php.