28 messages in org.oasis-open.lists.security-servicesRe: [security-services] Use Cases| From | Sent On | Attachments |
|---|---|---|
| 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: | John Kemp (onez...@bcn.net) | |
| Date: | Nov 26, 2003 6:20:27 am | |
| List: | org.oasis-open.lists.security-services | |
Mike, Greg et al,
See comments inline:
On Tuesday, Nov 25, 2003, at 14:55 US/Eastern, Greg Whitehead wrote:
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.
I think that Greg's proposal is an excellent one. I would also point out that individual SPs have a lot of control over what they do locally - they can invalidate a user's local session at any time they wish to, without requiring any global protocol to manage it. With the ability to force re-authentication at a certain time after the previous authentication, through the protocol, they get even more control over this process. I've cc'd Scott who's working on the SSO requirements to make sure he sees this.
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).
Yes, exactly... we're not precluding effective idle timeouts by not including such facilities in the SAML protocol. And we're also not precluding the possibility of individual implementations from developing a global idle timeout facility.
- JohnK