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