|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 11:24:14 am|
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 clearly stated business scenario does call for global idle time tracking, but something is better than nothing.
Now did that make sense?
-----Original Message----- From: John Kemp [mailto:onez...@bcn.net] Sent: Monday, November 24, 2003 2:04 PM To: Beach, Michael C Cc: secu...@lists.oasis-open.org Subject: Re: [security-services] Use Cases
I only just noticed that your use-cases were all session-related. I apologize for not replying to this email earlier. You describe in your use-cases three separate ecosystems (for session usage) that all share an IdP. Each ecosystem may have its own idle timeout value set that does not impact the other ecosystems. Although I'm not finished with a solution proposal, my idea is basically that although you may have a single IdP (or authentication authority), responsible for authenticating users from all ecosystems, you might also have a separate *session* authority for each of the ecosystems. Thus the 20-minute and 1-hour timeout sessions would not cause any issues, as they would have been issued by separate session authorities. The session authorities would refer to an authentication authority (which could be the same one for all, or a different one for each) to provide authentication services.
Does that make sense?
On Thursday, Oct 23, 2003, at 15:51 US/Eastern, Beach, Michael C wrote:
As I agreed, I have attempted to some use cases that Boeing would like to see addressed. We would implement the described functionality immediately if it were possible with our technology. The use case descriptions are attached.
This could be considered a draft that may be refined after comments.
Mike Beach Associate Technical Fellow The Boeing Company (425) 865-4404
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.