shibboleth-dev - Re: More defined custom extensions mechanism
Subject: Shibboleth Developers
List archive
- From: Chad La Joie <>
- To: Shibboleth Developers <>
- Subject: Re: More defined custom extensions mechanism
- Date: Wed, 06 Jul 2005 18:08:07 -0400
- Organization: UIS - Project Sentinel
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.
Ian Young wrote:
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
--
Chad La Joie 315Q St. Mary's Hall
Project Sentinel 202.687.0124
- Re: More defined custom extensions mechanism, (continued)
- Re: More defined custom extensions mechanism, Tom Scavo, 07/06/2005
- RE: More defined custom extensions mechanism, Scott Cantor, 07/06/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/06/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/06/2005
- Re: More defined custom extensions mechanism, Walter Hoehn, 07/06/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/06/2005
- Re: More defined custom extensions mechanism, Walter Hoehn, 07/06/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/06/2005
- Re: More defined custom extensions mechanism, Chad La Joie, 07/06/2005
- RE: More defined custom extensions mechanism, Scott Cantor, 07/06/2005
- Re: More defined custom extensions mechanism, Ian Young, 07/08/2005
- Re: More defined custom extensions mechanism, Tom Scavo, 07/08/2005
- Re: More defined custom extensions mechanism, Ian Young, 07/08/2005
- Re: More defined custom extensions mechanism, Ian Young, 07/09/2005
- RE: More defined custom extensions mechanism, Scott Cantor, 07/09/2005
- Re: More defined custom extensions mechanism, Ian Young, 07/09/2005
- RE: More defined custom extensions mechanism, Scott Cantor, 07/09/2005
- Re: More defined custom extensions mechanism, Ian Young, 07/11/2005
- RE: More defined custom extensions mechanism, Scott Cantor, 07/11/2005
Archive powered by MHonArc 2.6.16.