OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [security-services] AI 60 - Dynamic Session Material

It gets rather confusing, but I will give it a try.

Suppose we have an "ecosystem" that has resources (SPs) with different timeouts.  Say some are 1 hour and others are 20 minutes.  (For purposes of this description, timeout will refer to the idle timeout.)

Remember that the intent of a 20-minute timeout (at least in my world) is to ensure that if a user walks away from their workstation (which actually violates company policy, but that is another matter), these applications are locked against authorized access after 20 minutes.  If we mix these 20-minute timeout applications with say 1-hour timeout applications we cannot guarantee the results enforce this requirement

Anomalies/Unclear Behavior:
A user attempts access to 1 of the resources with a 1 hour timeout.  User is requested to authenticate and is issued a session credential for all resources in the ecosystem.  The user may, or may not, interact with other 1 hour timeout resources.  

Unclear 1:
The user is then idle for 20 minutes, then attempts access to a 20-minute timeout resource.  Are they already timed out?  They have actually never accesses a 20-minute timeout resource, so should they be granted access as a part of the session SSO interaction?

Unclear 2:
Whether or not the user should be reauthenticated above is unclear.  Regardless, the user now interacts with 1 or more 20-minute timeout resources.  The user then goes back to interacting with 1-hour timeout resources for more than 20-minutes.  The user returns to a 20-minute timeout resource.  Is the user now timed out?  The user has not been idle in the "session" for more than 20-minutes, but has been effectively idle relative to the 20-minute timeout resources.  If you answer no, then you have introduced the requirement for the session authority to keep track of all idle times (no navigation occurring) that might be relative to resources belonging to the session ecosystem.  That does not seem practical.

Unclear 3:
The user has been interacting with a 20-minute timeout resource.  The user is idle for more than 20 minutes.  If the next action is to attempt interaction with the 20-minute timeout resource, it is rather obvious the user should be considered timeout out and be required to reauthenticate.  However, if after the 20+ minute idle time, the next user action is to attempt access to a 1-hour timeout resource, the user is obviously not timed out.  Is the session idle time reset, which would mean the user can now go back to the 20-minute timeout resource without reauthenticating?  This would effectively be a back door allowing circumventing the 20-minute timeout.

What we want to guarantee is that between the latest authentication and access to the 20-minute timeout application, we have no period in which the user was idle for more than 20 minutes.  The only I can see to guarantee that is:
1) Require the user authentication the first time accessing a 20-minute timeout resource.
2) From the time of the above authentication, timeout the resource as soon as it has not been "touched" for 20+ consecutive minutes.  This is done regardless of what other resource the user may interact with (unless it was a case of interacting with other 20-minute timeout resources).
3) Once the 20-minute resource has been timed out, the next attempt to access requires a reauthentication.

So, effectively the 20-minute timeout resource(s) must behave as if in a different user session that is not federated (for SSO purposes) with other sessions.

Hope that is somewhat clear.


-----Original Message-----
From: Steve Anderson [mailto:sanderson@opennetwork.com]
Sent: Thursday, October 23, 2003 4:10 PM
To: Beach, Michael C; John Kemp
Cc: security-services@lists.oasis-open.org
Subject: RE: [security-services] AI 60 - Dynamic Session Material 

Just so I'm clear, can you elaborate on the "interaction anomalies" mixing SP timeouts?
Steve Anderson

-----Original Message-----
From: Beach, Michael C [mailto:michael.c.beach@boeing.com]
Sent: Thursday, October 23, 2003 7:05 PM
To: John Kemp; Steve Anderson
Cc: security-services@lists.oasis-open.org
Subject: RE: [security-services] AI 60 - Dynamic Session Material 

Based on yesterday's F2F discussion, I am of the impression this item may change significantly.  However, there is a point in this I am adamant about:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]