Feature/19 local dynamic metadata provider

[brzler]

Adds the OIDC-equivalent of Shibboleth's LocalDynamicMetadataProvider (https://wiki.shibboleth.net/confluence/display/SP3/MetadataProvider).

Uses Java NIO2's WatchService to handle Metadata file changes.

[brzler]

for feature request #19

[Sheldor5]

exactly what was missing, hope this gets merged

[tbrandstetter]

@scantor are you going to merge this feature to the Shibboleth OIDC version 3.x? It would be a great benefit like the LocalDynamicMetadataProvider for SAML2.

[scantor]

Not sure you're asking me specifically, but my answer would be just use SAML metadata and the existing LocalDynamic provider.

[tbrandstetter]

I'm looking for a solution for OIDC metadata (json files). For SAML the existing LocalDynamic provider works without a problem. Reading the docs of Shibboleth for the new OIDC OP version 3.0.0 there is only the filesystem metadata provider (with a static json) and the storage metadata provider for dynamic registrations available.

This pull request is closing the gap between the SAML dynamic metadata and OIDC. Thus, I'm asking for implementation in Shibboleth if possible. Sorry, if this is the wrong place - but the pull request is here and ready. Furthermore, it seems that this repository is abandoned and ongoing development is taking place in Shibboleth now.

[scantor]

Henri is still the lead on that part of the code, but this isn't where we're tracking issues anymore for the code now.

As for the request, we support and greatly favor SAML metadata for OIDC, not JSON. The IdP bases most of its processing on that format and we cannot do the same things with the limited capabilities of this format. The 3.0 plugin does not solely support the JSON format, it supports SAML metadata, which is documented.

[tbrandstetter]

Thanks for your support. Seems I misunderstood the documentation. It's clear for me now.

[scantor]

Docs are a work in progress (to make a serious understatement), I'll take a look and see if it needs more context.

My concern with this kind of addition is that it's adding a big pile of duplicate code overlapping what we have now, so if we did it at all, I can bet it would have to be redone and based on the actual LocalDynamic classes (maybe this patch is, but I don't think so).

Ultimately really up to @hjmikkon whether we want to think about it but my hope is in practice it will become less interesting when people better grasp how powerful metadata-driven configuration is in the IdP. That also opens up the ability for Unicon's GUI to be used to manage OIDC metadata and settings.

[tbrandstetter]

https://wiki.shibboleth.net/confluence/display/SC/OAuthRPMetadataProfile?src=contextnavpagetreemode was the missing link :-)

I'm sure it is working this way and because of that I share your opinion about avoiding duplicate code. It makes no sense to maintain two places of metadata repositories for one identity provider.

Again, thanks for the fast and professional support.