Shibboleth Developers

[Ian Young <>]

Chad La Joie wrote:

> Instead, why don't you treat the configuration of your name 
> mapper the same way that all the other components like this (name 
> mappers, artifact mappers, protocol handlers, etc) are configured in the 
> IdP?

Just to (possibly over-) broaden the question a little bit, I was 
wondering recently whether there was a place for a mechanism to provide 
configuration (and loading) of general plugins from the idp.xml, outside 
the classes currently supported (name mappers, metadata providers, etc)

I guess it would need some kind of <Plugin> extension to the idp.xml 
schema, plus a little bit of cut-and-paste in IdPResponder.java.  So, 
not heavy.  I can hack up something like this if people want to look at 
something concrete.

The main objection I can think of to this is that anything that is 
outwith the currently defined categories doesn't have any place to hook 
into the rest of the code, so it has a problem doing anything useful. 
The thing I'm interested in myself falls into this category: I have some 
code I wrote for the 1.2 IdP that does behind-NAT address mapping, but 
it would have to hook the call to request.getRemoteAddr() in 
ShibbolethV1SSOHandler and for now that would mean patching the code 
there... so acting as a "generic plugin" doesn't help a huge amount.

However, having a general configuration and loading hook would reduce 
the amount of code I'd have to patch in order to make this work, and 
provide me with a way to configure it that didn't involve opening my own 
configuration file or just changing the code to reconfigure.

Sorry if this is way off topic, but any comments on the general idea?

        -- Ian