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] | [Elist Home]


Subject: RE: [Sessions] Agreed points from 5/25 telecon


This discussion has been dead for a bit (seeing as I am working on a
Sessions presentation) I need to breath some life back into it. 

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Thursday, May 31, 2001 3:38 PM
To: security-services@lists.oasis-open.org
Subject: [Sessions] Agreed points from 5/25 telecon

[stuff deleted]

If the local timeout is shorter than the global, then when a user times out
locally they are logged out locally. If the user returns before the global
timeout, they will presumably present a ticket and things will proceed just
as if the user had never been to that site before.

Although this is certainly a valid way of operating it bothers me that, as
an ASP developer, there would be no way for me to defer the local
timeout-induced-logout based on the fact that the global session is still
active (if I so chose). The reason for doing this is that I don't want to
lose the user's local session state, but I also do not want to have to write
a bunch of extra code to save the user's state on timeout and restore the
user's when they return. Imagine working with some application and entering
data for 20 minutes, being pulled away to some other application for 30
minutes, then coming back to find your 20 minutes of work flushed down the
drain because, to the first application, it looks like you timed out then
logged back in again. I think one of the services the Session Authority
should provide is to answers questions like "To the best of your knowledge,
is global session XYZ sill active?". Individual applications can make use of
this service as they see fit, but they are not required to.

If the local timeout is longer, the participant site will simply ignore the
global logout and perform local timeout. Essentailly this is a variant on
ignoring the global logout and continuing until the assertions expire.

I don't  really see the usefulness of distinguishing based on the relative
lengths of the local and global timeouts. If the local timeout is larger
than the global timeout, it is still possible that the user could be busy
with some other session participant at intervals that are always less than
the global timeout, but together are greater than the local timeout.
W/respect to my comments above, I may still want to keep a local session
open if I know that the user is busy somewhere in the system.



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


Powered by eList eXpress LLC