RE: [security-services] Use Cases

["Beach, Michael C" <michael.c.beach@boeing.com>]

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?

Mike

-----Original Message-----
From: John Kemp [mailto:onezero@bcn.net]
Sent: Monday, November 24, 2003 2:04 PM
To: Beach, Michael C
Cc: security-services@lists.oasis-open.org
Subject: Re: [security-services] Use Cases


Mike,

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?

- JohnK

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
>
> <CorporateUseCases.doc><smime.p7s>

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.