Shibboleth Developers

[Chad La Joie <>]

I think Scott expressed this all pretty well in his reply, but for  
completeness, these questions are all out of scope for this discussion.

On Jul 17, 2006, at 2:50 PM, Tom Scavo wrote:

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