Shibboleth Developers

["Tom Scavo" <>]

Chad, before I consider any of your specific questions, would you (or
someone else) comment on the overall design goals with respect to the
Java SP?  For instance, you mentioned a couple times in passing that
the Java SP should be compatible with the C++ SP.  If that is an
explicit design goal, then any discussion re requirements and
functionality is an academic exercise, is it not?

If functional compatibility with the C++ SP is a goal, then what
subset of the overall functionality of the C++ SP will be implemented
in Java SP 1.0?  Certainly it's not possible to duplicate the rich
functionality of the mature C++ SP in such a short time frame.

Speaking of overall design goals, a more layered, compartmentalized
architecture would be desirable.  In other words, if the architecture
were not so tightly bound to the browser profiles, the Java SP
implementation might be brought to bear on other problems.

I know you asked not to deviate from the questions posed, but I wonder
if considering functionality first might be putting the cart before
the horse.  What are the overall design goals of the Java SP?  What
SAML profiles will it support?  What are the driving use cases?  Most
importantly, should the Java SP be compatible with the C++ SP, and if
so, what level of compatibility is sought?

Tom

On 7/17/06, Chad La Joie 
<>
 wrote:
> 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?