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

["Conor P. Cahill" <concahill@aol.com>]

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