[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Server-Side State and Stateful Sessions
I would think that generally there would be a trade-off between performance/scalability and the "quickness" with which a system enforces a logout request. In the implementation with which I am very familiar, we are talking about cache refresh settings. We did work to find a balance between network traffic, directory load, performance, and timing on enforcement of a change in access control. I think the requirements of the SP are a significant consideration here, and relate to the sensitivity of the data or transaction being requested. For highly sensitive transactions, the business could well have a requirement for instantaneous enforcement of a logout request. Conversely, if we were talking about browsing subscription-based content, urgency might not be a consideration at all. Not sure what this means to conformance, but it is how we established requirements for similar functionality. For us, enforcement of access control changes varies from SP to SP today as specified by the information owner. This assumes that slower enforcement means less load on the environment. Mike -----Original Message----- From: Scott Cantor [mailto:cantor.2@osu.edu] Sent: Friday, August 20, 2004 12:44 PM To: 'Mishra, Prateek'; security-services@lists.oasis-open.org; saml-dev@lists.oasis-open.org Subject: RE: [security-services] Server-Side State and Stateful Sessions > 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. The word database is maybe a bit strong, but yeah, some kind of "state" access. > 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. Well, I guess I'd say that in fact some systems *do* work like this and they scale for some definition of "scale". Maybe one way to look at it is that if there are simply not means to support the feature and scale to level X, then you maybe don't deploy the feature if you have to scale to level X, but could if you deploy to level Y < X. Presumably, X and Y are a basis of competition among implementations (said the guy who doesn't sell his ;-) -- Scott 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/l eave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]