Shibboleth Developers

[Ian Young <>]

Chad La Joie wrote:

> I guess I'm not quite sure what you mean Ian.  All the points that are 
> pluggable, I believe, are reflected in the idp.xml file already.  If we 
> did something as generic as you're talking about I'm not sure how the 
> IdP would know what the plugin was even for.

I tried to anticipate that question in my original post:

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

(My apologies for using "outwith", which I keep forgetting is 
"peculiarly Scottish".  Hopefully the meaning was obvious from context.)

So, I'm not interested in things that already have a place to plug in; 
that problem's solved.  I'm interested in providing *some* support for 
things that *don't* extend the IdP in ways the core team have 
anticipated, but in *new* ways.  Obviously that can't be *complete* 
support, but it might reduce the scope of changes that would need to be 
made to do something like this.

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

To do my NAT handling thing "properly", I'd have to maintain a patch 
that modifies the idp.xml schema, the servlet initialisation, the 
IdPProtocolSupport object and the line of target code in the protocol 
handler.  With some generalised support built-in, I'd just have to do 
the last of those (plus have the plugin communicate its configuration 
through some backdoor).

Some things developed against a generic plugin interface might 
eventually attract enough attention to warrant being included in the 
main distribution and acquire a more formal plug-in interface.  I'm just 
looking to lower the barrier to entry for development somewhat.

Assuming that I'm still the only person interested in a generic plugin 
mechanism, can I ask whether there is instead any general interest in 
creating a remote address mapping plugin mechanism instead?  In some 
ways, that would be my preferred approach but I'm wary of proposing 
something that touches several places in the IdP code at this point in 
the cycle.

Just to be specific, such a plugin would be handed the RelyingParty and 
the remote (client browser) address, by the ShibbolethV1SSOHandler, and 
given the opportunity to return a different remote address for use in 
creation of the SAMLAuthenticationStatement.

        -- Ian