Shibboleth Developers

["David L. Wasley" <>]

I certainly second everything Bob said (unusual for me, I know :-) 
and wanted to add a thought or 2.

The notion of a "session" is problematic simply (I think) because 
there is no good way yet to know when the session owner is no longer 
in control of it, or better, when someone else assumes control of it. 
So, the more places we instantiate "session" with respect to the same 
system, the harder it becomes to synchronize, coordinate, etc. 
"session" behavior.  Hence stateless is good.

However, I have always thought of the handle as a self contained 
object, meaningful to the HS and the AA.  It does have a "session" 
(validity period) for that reason.  Seems better here than in the HS 
or the AA (or both).  Having said that, it might be important for 
some target applications that the mapping be logged for later problem 
resolution.

Bob, Can you elaborate a bit on what you mean by

> 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.

and why it is an issue?

Thanks,
        David

-----
At 12:57 AM -0700 on 5/15/02, RL 'Bob' Morgan wrote:

> 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--