|Beach, Michael C||Oct 23, 2003 12:49 pm||.bin, .doc|
|John Kemp||Nov 24, 2003 1:58 pm|
|Beach, Michael C||Nov 25, 2003 11:24 am|
|Greg Whitehead||Nov 25, 2003 11:50 am|
|Beach, Michael C||Nov 25, 2003 12:24 pm|
|Greg Whitehead||Nov 25, 2003 12:32 pm|
|John Kemp||Nov 26, 2003 6:20 am|
|Scott Cantor||Nov 26, 2003 8:22 am|
|John Kemp||Nov 27, 2003 7:49 am|
|Scott Cantor||Nov 28, 2003 9:30 pm|
|Conor P. Cahill||Nov 29, 2003 2:14 am|
|Conor P. Cahill||Nov 29, 2003 2:25 am|
|Conor P. Cahill||Nov 29, 2003 2:27 am|
|John Kemp||Nov 29, 2003 5:54 am|
|Conor P. Cahill||Nov 29, 2003 11:35 am|
|Beach, Michael C||Nov 29, 2003 11:37 am|
|John Kemp||Nov 29, 2003 11:52 am|
|Beach, Michael C||Nov 29, 2003 11:59 am|
|Beach, Michael C||Nov 29, 2003 12:03 pm|
|Conor P. Cahill||Nov 29, 2003 1:46 pm|
|Conor P. Cahill||Nov 29, 2003 2:59 pm|
|Anthony Nadalin||Nov 30, 2003 5:23 pm|
|Conor P. Cahill||Nov 30, 2003 7:18 pm|
|Conor P. Cahill||Dec 1, 2003 4:16 am|
|Anthony Nadalin||Dec 1, 2003 9:31 pm|
|Conor P. Cahill||Dec 2, 2003 4:38 am|
|Anthony Nadalin||Dec 3, 2003 4:36 am|
|Conor P. Cahill||Dec 3, 2003 4:54 am|
|Subject:||RE: [security-services] Use Cases|
|From:||Beach, Michael C (mich...@BOEING.COM)|
|Date:||Nov 25, 2003 12:24:40 pm|
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.
-----Original Message----- From: Greg Whitehead [mailto:gr...@trustgenix.com] Sent: Tuesday, November 25, 2003 11:56 AM To: Beach, Michael C Cc: John Kemp; secu...@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).