Shibboleth Developers

[Chad La Joie <>]

On Jul 17, 2006, at 4:23 PM, Scott Cantor wrote:

> > 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).
>
> As I alluded in my response to Tom, compatibility doesn't  
> necessarily mean
> no changes, it's more about what's in 2.0, but at the same time I  
> wasn't
> planning on wholesale changes here either.
>
> But there's the question of schema changes, I suppose. It would be
> reasonable to be more lax in 2.0 and stop validating. We could hack  
> in new
> features easier I imagine.

I didn't mean to imply that the C++ code couldn't change, but I  
didn't want to put words in your mouth either.

> > 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.
>
> Not in the way you mean. You can handle individual attributes as  
> you see fit
> and plug code in to extract the values however you want to, but you  
> only
> have access to one attribute at a time. It's not like the IdP  
> resolver.
>
> I don't think documenting it makes much difference. The code for  
> the new
> eduPersonTargetedID is exactly the code to copy, but people don't  
> want to
> write C++ and construct the project files around the code needed to  
> build
> extensions. I can't help that, aside from providing sample project  
> files I
> suppose.
>
> > 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.
>
> Presumably one can make things serializable, though, right?

Depends on the container, with Tomcat, no.  Other systems, like  
JBoss, allow for customer serializer's to be written.  Many just rely  
solely on the default serialization mechanism in Java which isn't  
extensible.

> Obviously, I think this is an approach we want, but at the same  
> time in Java
> it may be reasonable to provide some secondary mechanism. In  
> particular,
> couldn't we provide access to actual SAML objects through some  
> means? Rather
> than the base64 encoding I have to do?
>
> > 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?
>
> It's not specific to Java, but we need to revamp the whole export mess
> completely anyway.