Shibboleth Developers

["Scott Cantor" <>]

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

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

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.

-- Scott