Shibboleth Developers

["Scott Cantor" <>]

> It will be the same basic structure, an engine that reads in a resolver 
> configuration and executes a number of data sources to fetch raw 
> attributes and then attribute definitions to transform them.  The 
> resolver with keep a request-level cache that ensures resolved 
> attributes (raw or transformed) are kept around until everything is 
> resolved and may, optionally, be configured with a second level cache. 
> This second level cache, if used, will keep attributes around for either 
> a configurable amount of time or until the end of the session, whichever 
> comes first.  Like the current SP, attributes will be filtered based on 
> an acceptance policy.

I guess that's ok (the second level cache idea), but don't confuse it with
the requirement to cache the security token(s) that are acquired and are
part of the session. I could see it getting a little complicated to juggle
both caches here, and seems somewhat confusing.

> 2. How would developers expect to get at these attributes?  HTTP 
> headers, Request attributes, Session attributes?  Personally I think 
> HTTP headers are a *bad* idea.

They're bad, unless you have no alternative but a language-specific API in a
language-neutral world. Java isn't one, so there are better options, but
using Java sessions still make me very nervous without a lot of
cross-checking.

Personally, I favor per-request access to anything security-related, if
possible.

Another consideration is portability between the SPs. I don't think it's a
bad thing to support a model that is potentially the same between them, even
if there are other, better options added.

-- Scott