Shibboleth Developers

[Chad La Joie <>]

This is what I hope to be the first of a series of threads discussing  
core functionality within the Java version of the Service Provider.   
I ask that in these notes people keep comments targeted on the  
specific topic at hand and not broader issues that may be related  
(for example as this note is about handling attributes within the SP  
a broader, but inappropriate for this thread, topic would be  
attribute naming practices).

So, while on my way over here to London I was thinking, initially,  
about the Attribute Acceptance Policy (AAP) and then generally about  
how to handle incoming attributes.  I'm not going to address how the  
attributes are coming (push vs. pull) just assume for right now that  
they exist.

Should developers be able to define specific matching/filtering  
functors within the AAP in case the basic whole string and regex  
matching wasn't enough?  My initial thinking is yes, it wouldn't be  
at all hard to support and could offer people the ability to do some  
modestly advanced work.  However I believe such a thing would break  
compatibility between Java & C++ SPs (something the core team has  
thought would be a bad thing if it could be avoided).

Should developers be able to define something analogous to the IdP's  
attribute definition semantics that would allow certain  
transformation operations to be performed on the attributes  
(formatting, concatenating, splitting, etc)?  I believe the current C+ 
+ code does in fact have this ability now (Scott?) though it is bit  
difficult to use and completely undocumented.  This may be another  
case where, if this functionality was incorporated into the AAP, the  
Java & C++ SP AAPs may not be compatible.  However, this could be  
mitigated by using a separate configuration file, but that too has  
it's trade offs.

Once the attributes are filtered and mangled appropriately, where do  
they go so that application developers can access them?  To date my  
thinking has always been the HttpSession for the application.  This  
could cause some issues if used in conjunction with the previously  
proposed functionality.  If a developer uses a custom attribute  
handler to change an incoming attribute from a blob into some object  
that is not serializable and that is placed in the HttpSession then  
container managed session replication would break.  Not a good thing  
for clustered environments.  However, I still think the HttpSession  
is the only workable solution and SP developers will just need to be  
aware of this limitation in that given environment.

How often should attributes refreshed?  This is almost certainly  
something that needs to be controlled through a mixture of tunable  
settings at the SP and relevant information from the attribute  
assertion.

In terms of configurations files, regardless of the number we end up  
with for this stuff, they will be reloadable without taking down the  
SP however there will also be the option to disable this feature.  To  
me, the ability to turn this off is important in well managed  
production environments where changes are usually staged in  
preparation for an outage window and then, during that window, enacted.

What other issues/features/concerns with handling incoming attributes  
to others have given a scope of a service provider meant strictly for  
Java web applications?