[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]