Custom metadata provider

[Cantor, Scott]

On 12/9/15, 11:49 AM, "dev on behalf of Rod Widdowson" <dev-bounces at shibboleth.net on behalf of rdw at steadingsoftware.com> wrote:


>
>I'd start by looking at
>org.opensaml.saml.metadata.resolver.impl.FilesystemMetadataResolver (but
>remember that many of the objects it inherits from are in the impl tree)

I might be misremembering, but I think Brent might have been intending to start moving some of the base classes up once the indexing stuff and the issues Marvin's working on get worked out. If not, I'd suggest it. Keeping things in -impl was a time-saver to avoid having to commit but I would like to see us commit at some point.

>Alternatively you could do this in native spring by summoning up your bean
>and putting it in to a
>net.shibboleth.idp.saml.metadata.RelyingPartyMetadataProvider.  Then put
>that SpringFile which defines the those beans into the lisyt beal called
>"shibboleth.MetadataResolverResources".

I suspect a database version wouldn't need much configuration other than a reference to a DataSource bean, so the parsing would be relatively simple.

>Were it feasibly, a much better solution would be to build something which
>implements org.springframework.core.io.Resource and/or
>net.shibboleth.utilities.java.support.resource.Resource and plug that into a
>org.opensaml.saml.metadata.resolver.impl.ResourceBackedMetadataResolver

That would work if the goal is to feed an octet stream, but I would expect a database approach is possibly more about avoiding the XML entirely.

-- Scott