Extending the SP Dynamic Metadata Provider

[Rod Widdowson]

Those of you with Jira feeds will know that I’ve been looking at the SP Dynamic Metadata provider recently with a view to making it
more functionally equivalent to the IdP one.

As a quick recap there are currently 3 ways to configure Dynamic Metadata into the SP:  Well Known, Regex and Template.  The IdP has
basic DynamicHTTPMetadataProvider configurations which match.  The IdP exploits IoC which allows it to do things (such as the SHA1
hash of the entityID) in a much more general manner than the SP.

The SP also allows the generated URL to use the "file://localhost/" (usually elided to "file:///") paradigm which allows it to mock
up the work that the IdP’s LocalDynamicMetadataProvider does.

The SP does not have explicit configuration for the MDQ protocol the way that the IdP does with the MetadataQueryProtocol element
but it can be mocked up using the template:

	<Subst>http://MQServer/entities/$entityID</Subst>

The SP allows some configuration of TLS on the Dynamic connection – which the IdP achieves by allowing injection of a custom crafted
HttpClient.

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>

2)	More intuitive configuration of Directory based dynamic lookup.  

This would be to align it better with the IdP's LocalDynamicMetadataProvider (and there would be significate changes under the hood)

My suggestion would be to add new attribute "sourceDirectoryPath", yielding something like this:

	<MetadataProvider type="Dynamic" sourceDirectoryPath="/opt/sp/DynamicMetadata/" />

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

3)	Specify a backing cache directory for (HTTP) 

The idea is that after a reboot the SP would be able to lookup the local directory rather than reach out to the MDQ server.  This is
similar to the reload from backing store thing that the Batch providers do and would speed up restart.  This would be similar to the
configuring an IdP DynamicHTTPMetadataProvider with a persistentCacheManagerDirectory.

My suggestion would be to add new attribute "cacheDirectoryPath", yielding something like

	<MetadataProvider type="Dynamic" cacheDirectoryPath="mdqCache" >

A benefit to this approach is that all the changes are backwards compatible.

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?

I have an open UI to understand the TLS configuration in more detail, but if that can be changed in any manner it will be more
likely to affect the batch provider (which currently has limited TLS capabilities), although configuration would probably trickle up
to the Dynamic provider.

Finally I have not mentioned Artifacts in any of the above.  Although they are a nightmare in the situation when the Artifact is the
first time you have heard of the RP, they are a definite edge case on an edge case and completely orthogonal to this discussion.

Comments welcome, as always

Thanks