Extending the SP Dynamic Metadata Provider

Brent Putman putmanb at georgetown.edu
Mon Oct 30 17:11:04 EDT 2017



On 10/27/17 11:28 AM, Cantor, Scott wrote:
>> How do files end up in this directory and what is the file naming convention?
> Ideally there isn't one and it simply monitors the directory and loads what's there, but that's work.

For the IdP LocalDynamic- provider, the naming convention is a plugin,
see the 'sourceKeyGeneratorRef' property:

https://wiki.shibboleth.net/confluence/display/IDP30/LocalDynamicMetadataProvider

Default is lower-case hex encoding of SHA-1 hash of entityID.

So it's pluggable, but it can't be arbitrary and has to be known in
advance.  If it's literally load-on-demand (as the IdP LocalDynamic-
is), as opposed to the other approach of "periodically scan a directory
and load everything that's there", then you have to be able to map from
(at least) the entityID -> dynamic lookup key, and so you have to decide
a strategy in advance.

>> What file naming convention will be used in the cache dir?
> Unspecified, I would hope.

In the IdP, for all the dynamic providers, it's also a plugin configured
via 'persistentCacheKeyGeneratorRef', with the same defaults.

However, for the persistent cache, the use case is different than
primary dynamic lookup case above.  On startup/reload, it *does*
traverse that directory and load everything that's there that's 1) valid
(i.e. not expired) 2) passes an optional predicate.   If it's cache key
(e.g. file name) is not what would be expected based on the configured
key generator, then it renames the cache key accordingly.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20171030/ca1b9512/attachment.html>


More information about the dev mailing list