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

[Hal Lockhart <hal.lockhart@entegrity.com>]

You should combine this with my message from last week to the sub commmitte,
reproduced here. If I have time I will think more about the 2nd algorithm.

Hal

The thing to do next is loosely specify two algorithms for timeout decision.

In both cases, the session authority keeps a list of active sessions and the
last touch time it knows about. The touch time is set at global login and
updated every time a participant site joins the session. The SA will
porobably keep these sorted by touch time, with oldest first. The SA also
needs to keep a list of sites participating in each session to send
notifications.

The first algorithm is simpler, participants send the SA a list of sessions
and touch times at regular intervals, probably it should only send touch
times fresher than some value, which can be communicated in some setup
message. If the timeout is 5 min, the interval might be 30 sec. The SA
simply keeps its table up to date with the most recent time for each
sesssion. When the touch time for any session goes over the timeout, timeout
has occurred. If the SA gets a message from a site about a session it is not
listed for it should be added to the list.

The second algorithm is more complicated, but I think could be more
efficient, I am not sure. When the SA sees that a session is old enough to
timeout, it queries all the sites that are participating. They send all the
session touch times newer than some value, as above. The efficiencey comes
from both the potentially longer interval and the fact that you learn about
other sessions at the same time. I think the SA needs to also keep a
freshness of update for all participant sites. It should not query if the
info from a site is fresher than some value. I haven't walked thru this one
completely.

Once we have them we need to compare them for number of messages sent and
how soon after true timeout does timeout get detected. These should be
looked at under various assumptions of number of total sites, average number
of sites per session, various time values. 

The other major question is, how does a RP know if it has to worry about
dynamic session semantics. The two main answers I see are 1) configure out
of band and 2) some element in the assertions issued. This could also be
done in a steup, but I don't see any reason right now that participants need
to declare to the SA that they are "doing sessions." It seems they can just
ask for info about particular sessions.


> -----Original Message-----
> From: Pilz, Gilbert [mailto:gpilz@jamcracker.com]
> Sent: Thursday, June 21, 2001 4:00 PM
> To: Hal Lockhart; security-services@lists.oasis-open.org
> 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.
>