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] Server-Side State and Stateful Sessions


Obviously I am not thrilled about making SOAP based SLO mandatory,
because I think this doesn't fit well with many implementations'
architectures.  It can be accommodated to a degree, but there are going
to be usability side-effects, like possible repeated logouts.  

But I understand the desire to be able to send a logout message over
SOAP in unusual circumstances, like suspected account compromise.  In
such cases, these side-effects are acceptable.  But for normal cases,
the SOAP form isn't appropriate (for such implementations).

So, if we insist on keeping the SOAP based SLO mandatory, I propose we
add some text that explains that some implementations do not lend
themselves well to logout messages that are not sent through the user
being logged out, and that SOAP based logouts should be used with such
implementations only in circumstances that require it, such as suspected
account compromise.
--
Steve Anderson
OpenNetwork
 

> -----Original Message-----
> From: Conor P. Cahill [mailto:concahill@aol.com]
> Sent: Friday, August 20, 2004 4:45 PM
> To: Mishra, Prateek
> Cc: Scott Cantor; security-services@lists.oasis-open.org; saml-
> dev@lists.oasis-open.org
> Subject: RE: [security-services] Server-Side State and Stateful
Sessions
> 
> 
> 
> Mishra, Prateek wrote on 8/20/2004, 3:31 PM:
>  >
>  > The challenge here is that database lookup is now required
*everytime*
>  > the user accesses a resource. Otherwise, we might unknowingly
permit
>  > access even with an invalid session.
> 
> I can think of ways that this can be done without requiring a database
> lookup (at least for the majority of client accesses).  For example,
> you could set things up so that you kept track of a "last SLO"
timestamp
> and you only needed to do the database operations for incoming
requests
> that have a session that was last checked against the database prior
> to the "last SLO".
> 
> I'm sure we can come up with others that enable this to be implemented
> fairly easily or cost effectively.
> 
>  > To my knowledge, most commercial web access systems avoid this type
of
>  > architecture as it is unlikely to scale under load. I do have to
>  > express my concern that the SAML 2.0 specification is mandating
>  > features that have yet to be proven to scale in deployments.
> 
> However, most commercial web access systems that have to deal with
> live user sessions *and* scalability, have some form of server side
> session information and therefore can deal with the SLO operation
> fairly easy.
> 
> It's the implementations that place *all* of the session information
> into a cookie that have some form of persistent information to
maintain
> with regards to an SLO operation.
> 
> Note that I'm not too concerned about the revocation (which an SLO
> essentially is) database lookup upon receipt of a new assertion.  The
> rest of the parsing of the assertion is probably nothing in comparison
> to the check for revocation.
> 
> Conor
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster
of
> the OASIS TC), go to http://www.oasis-
>
open.org/apps/org/workgroup/security-services/members/leave_workgroup.ph
p.



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