Extending the SP Dynamic Metadata Provider

Cantor, Scott cantor.2 at osu.edu
Wed Oct 25 14:54:26 EDT 2017


On 10/25/17, 5:04 AM, "dev on behalf of Rod Widdowson" <dev-bounces at shibboleth.net on behalf of rdw at steadingsoftware.com> wrote:

> It seems to me that three changes to the configuration (and thus implementation) would be advantageous
>
> 1)	More Intuitive configuration of MDQ setup.
> 
> This will be the most common setup and to simplify it I’d propose a similar extension to the IdP:
>
>	<MetadataQueryProtocol>http://mdq.example.org/global/</MetadataQueryProtocol>

I guess that makes sense, though I wonder if we want to just define an alternate plugin type/synonym for this and bake in a simpler set of assumptions altogether. Then the URL can be an attribute inside the MetadataProvider element and be done with it.

> This would allow us to deprecate (but not disallow) file:// URLs.

I don't know that I want to maintain a second way to do this when it really hasn't been used much anyway, and there's a nasty pass through to curl involved here that probably isn't a great thing to keep. I did it because it was a free side effect but if we make it a real feature, I think we should wrap all of it.

> As far as configuration goes, that’s all I can see by way of low hanging fruit.  Have I missed something?  Or have I got something
> wrong?

The only thing I know of offhand, without a lot of familiarity with the IdP version, is the preload option, to pull in uncached copies of particular IdP metadata at startup.

-- Scott





More information about the dev mailing list