Group 3: Sessions

["Orchard, David" <dorchard@jamcracker.com>]

Based upon your suggestion, I'll move this to the use case list..  I've also
changed the subject line.

I disagree with the notion that logout in distributed environments being
difficult as difficult as you say because of the environment we are in.
Session mgmt is in the web browser use case.  For them to have clicked the
"logout" button, they have done an action on a web site, thus breaking the
connection to the process that they may have been previously performing.  If
the logoff (or a stop or a different process button is pressed) is done at
the same web site as the non-instantaneous process, the site will have to
clean up the process anyways - regardless of whether we say logout is in
scope or not.  If the break action (logoff...) is done at a different site -
such as the source site - then the non-instantaneous process web site is
still going to have to cleanup as the tcp connection got broken.  So whether
the process web site hears about a break from an external saml call to
delete the session or it notices it when it's HTTPOutputStream generates an
exception, it's still going to have to muck about to clean things up.  

So to me there is no issue of distributed environment for non-instantaneous
processes.

On the issue of the client tracking all the sites participating, it's
actually the source web site that tracks the destination web site.  And the
source web site is going to have to know a priori about possible destination
web sites - because it will have to know either who to push a SAML request
to or who to send a SAML response to.  So it's trivial to track which are
the active destination web sites participating in the session.  

Our model is that assertions can time-out, but the timeouts are based upon
touch times rather than first access.  Although I could see how there could
be configuration to determine either mode/profile and would be comfortable
in allowing both cases.

So I don't see the difficulties that you are concerned about.  Please
disabuse me of my ignorance on this.  

Cheers,
Dave

> -----Original Message-----
> From: George_Robert_Blakley_III@tivoli.com
> [mailto:George_Robert_Blakley_III@tivoli.com]
> Sent: Sunday, February 25, 2001 8:00 PM
> To: Orchard, David
> Subject: RE: Ballot Attached - Group 3: Sessions
> 
> 
> David,
> 
> Thanks for your question.
> 
> I didn't really try to explain, as I was rushed for time to 
> get my vote
> in... I'm sorry if I was obscure.
> 
> My rationale is that tokens should time out (i.e. have 
> expiration dates)
> and that if a server which has
> received a token chooses to establish a session based on the 
> token (which
> it would do outside the
> scope of our specification) then it could use the expiration 
> date/time as
> the time at which to time the session out.
> 
> Logout in distributed environments is extremely difficult as 
> it involves
> the client (or something else)
> knowing what sessions have been established, and being able 
> to contact the
> correct servers to
> perform the logout.  It's even more complicated if non-instantaneous
> transactions are still running, as
> you have to decide what to do when a server running such a 
> session receives
> a request to log out.
> 
> If you feel it would be useful to others, you can feel free 
> to post this
> correspondence to the list.
> I'd also welcome further questions if this is obscure, or if 
> you think I'm
> badly mistaken.
> 
> --bob
> 
> Bob Blakley
> Chief Scientist
> Enterprise Solutions Unit
> Tivoli Systems, Inc. (an IBM Company)
> 
> 
> "Orchard, David" <dorchard@jamcracker.com> on 02/25/2001 08:54:57 PM
> 
> To:   George_Robert_Blakley_III@tivoli.com
> cc:
> Subject:  RE: Ballot Attached - Group 3: Sessions
> 
> 
> 
> I don't see the logic behind your votes.  I was surprised to see No to
> session mgmt, no to logout, but yes to timeout.  How can 
> there be timeout
> without session management?  How is invalidating via logout 
> much different
> than timeout?
> 
> I'm curious as I think the vote results are going to be very 
> confusing..
> 
> Dave
> 
> > -----Original Message-----
> > From: George_Robert_Blakley_III@tivoli.com
> > [mailto:George_Robert_Blakley_III@tivoli.com]
> > Sent: Friday, February 23, 2001 2:49 PM
> > To: Darren Platt
> > Cc: UseCaseList
> > Subject: RE: Ballot Attached - Group 3: Sessions
> >
> >
> > All,
> >
> > Here's my vote on issue group 3:
> >
> > (See attached file: Group3VoteBlakley.html)
> >
> > --bob
> >
> > Bob Blakley
> > Chief Scientist
> > Enterprise Solutions Unit
> > Tivoli Systems, Inc. (an IBM Company)
> >
> 
>