RE: [security-services] Use Cases

["Conor P. Cahill" <concahill@aol.com>]

Anthony Nadalin wrote on 11/29/2003, 11:04 AM:
 >
 > >I think that the IDP has to have some form of SessionIndex on it's
 > assertions in order to properly handle Single-Log-Out in a world where
 > the
 > user may have >multiple simultaneous authentication sessions (such as
 > browsers on two different computers -- where logging out of SSO on one
 > computer shouldn't impact your >session on the other computer).
 >
 > This does not have to be a SessionIndex, it just has to be some
 > form of state.

It has to be some form of state that does not mute the pseudonymity of 
the nameidentifier.  SessionIndex was a simple, elegent solution. 
Others (such as per-SP random Session Identifiers) would work as well 
and, in some casees, have been implemented by some using the 
SessionIndex field.

 > > But the SP can't signal (to anybody other than the user) that
 > > it's local session has been terminated.  We could add SPLO (SP
 > > Log Out) capability (for the SP to be >alble to tell the IdP
 > > that the SPs session initiated by the SSO has been terminated)
 > > to the SLO protocols if we feel that is necessary.  However,
 > > the only effect of such a call would be that the IdP
 > > would not send an SLO notificcation to thhat SP should real SLO be
 > > initiated at the IdP.  The SPLO would not cause the IdP to send SPLO
 > > notifications to other SPs.
 >
 > Is this a Liberty design artifact ? I agree that there should be a
 > mechanism for a service provider to signal a session termination or
 > re-authentication required.

Liberty allows the SP to indicate to the IdP that the authentication 
session managed by the IdP is to be terminated (SP Initiated Single 
Log-Out). Liberty also allows the SP to ask the IdP to re-authenticate 
the user at this time (ForceAuthn).

Liberty does not have an existing call that the SP can use to tell the 
IdP that the SP's local session has ended (although if the SP 
subsequently sends an AuthnRequest to the IdP, the IdP can probably 
figure out that the previous local session at the SP has been 
terminated, but that would just be an assumption).

If people feel that this would be a usefull call (so the SP can say to 
the IdP "hey, the user who you asserted at my site is done and is 
leaving").  The IdP would not treat this as an SLO.  The call would 
likely result in the IdP removing the "i've sent an assertion to this 
SP" record in the session information for the users authentication 
session at the IdP.

Of course, if we were to do that, we would have to have protocols to 
enable it on the back channel (a SOAP interface accessed directly by the 
SP) and on the front channel (a redirect of the user's browser from the 
SP to the IdP).  The front channel is needed for IdPs that store session 
information on the user's browser.

Conor

Conor