SP V3 metadata types

[Brent Putman]

On 6/11/18 3:46 PM, Tom Scavo wrote:
>
> The current implementation of DynamicHTTPMetadataProvider caches
> entity metadata in a local directory (if
> persistentCacheManagerDirectory is specified) but then the cache is
> treated as nothing more than a glorified backing file (at least
> AFAICT). The provider needs to be smarter about how it leverages
> cached metadata.

Like Scott, I don't think we agree on what "smarter" could mean.  Are
you perhaps missing that the metadata in the persistent cache is loaded
into memory on every refresh? (as long as still valid, not expired,
etc)  What that means is that, once it's primed into the provider by
the first request for it [1], it's going to effectively be available
for as long as it is still valid - the same as an aggregate would be.

At that point it effectively is "local", in that no query is attempted
for those entities, and it doesn't matter whether the source server is
available etc.  Isn't that what you're essentially trying to do with
the notion of the separate batch provider accessing an aggregate of
"high value" entities?

[1] As far as priming the dynamic providers, Scott mentioned the use of
a script to issue requests.  I can't remember whether we built an admin
endpoint into the metadata service to do that (as opposed to just
issuing IdP-initiated requests whose responses you just disregard).  We
could.  But the other approach we talked about was a simple Spring bean
that would take a metadata resolver ID and a list of entityIDs and just
do the resolution/priming internally on IdP (re)start.

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