Shibboleth Developers

["RL 'Bob' Morgan" <>]

Some rambling on this topic.

In general I think it's a good thing if, all other things being equal,
server operations can be stateless; that is, not requiring state to be
saved, and shared among replicated server instances, and later
removed, etc.  In particular I think it's possible for the Shib HS to
generate handles in such a way that no per-handle-generation state
needs to be saved, unlike our current design where the mapping between
temp handle and permanent userid is saved in a database.  The idea
would simply be to put an encrypted userid in the handle that could be
decrypted by the AA when processing an attribute request (I'll call
this a "self-contained handle").  This would permit the HS and the AA
to be completely decoupled, which is a good thing.  But this got me
thinking about possible implications of handles and sessions.

One observation is that the SAML Artifact profile pretty much requires
saving per-artifact state at the authentication authority to support
subsequent retrieval of the authn assertion.  So this could be one of
the advantages of the POST profile, that the authn assertion can be
sent on its way at generation time and need not be retained by the
handle server.

Handles are supposed to be temporary, so a self-contained handle would
have to have a timestamp in it to indicate its lifetime.  This is easy
enough.  The AA would treat an expired handle like a non-matching one.

I think the most concrete question is whether the Attribute Authority
in the Shib scenario needs access to the entirety of the
authentication assertion in order to properly answer an attribute
query.  I am inclined to say that it doesn't.

A related question is whether the attribute query can simply include
the authentication assertion by way of identifying the subject.  I'm
pretty sure this was proposed, and supported by the schema at some
point, but it seems to me that this is not possible with the current
schema.  Am I missing something?

A more general question is whether the HS will want to save some state
about user authentication in order to support what SAML folks like to
call "dynamic sessions", aka "rich sessions", supporting things like
logout-from-all-apps, cross-app inactivity timers, etc.  One answer to
this is that this is really local WebISO functionality rather than HS
functionality.

Anyway, I'm inclined to think that designing a self-contained handle
would be a good thing.  I have some more specific ideas on how to
implement this.

Thoughts?

 - RL "Bob"


------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--