[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:firstname.lastname@example.org] > Sent: Friday, August 20, 2004 4:45 PM > To: Mishra, Prateek > Cc: Scott Cantor; email@example.com; saml- > firstname.lastname@example.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.