Shibboleth Developers

[Chad La Joie <>]

We've often heard two feature requests on the SP side of things:
  - The ability to pull attributes from multiple sources (e.g. local 
databases, other attribute authorities, etc)
  - The ability to transform an attribute (e.g. base64 decode)

For those familiar with the IdP you might say "isn't that what the 
attribute resolver does?" and of course you'd be right.  So I'm 
currently looking at including an attribute resolver in the SP.

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.

While I believe this model will allow the two uses cases above (and many 
more) to be met, I currently have no intention of shipping code that 
would allow people to contact another SAML IdP for attributes.  This is 
certainly doable, and the design is meant to allow that, but there are 
currently to many deployment specific variables to provide a useful data 
connector.

Some questions that remain outstanding are:

1. Attributes may come from multiple sources, via data connectors, and 
be created through attribute definitions.  Where should the attributes 
be filtered?  Filtering attributes at the end would require some sort of 
source tracking ability and that source may not always be clear (think 
of an attribute, created by a definition, using values from two distinct 
connectors).  Personally I'm favoring only applying the attribute filter 
to data coming in from data connectors.

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 easy to spoof, have length 
restrictions in most web servers, and various other issues.  Request and 
 session attributes seem reasonable.

Other thoughts and comments on this?
--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124