RE: [security-services] Server-Side State and Stateful Sessions

["Beach, Michael C" <michael.c.beach@boeing.com>]

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.