LocalDynamicMetadataProvider at the SP

[Nate Klingenstein]

Martin,

> is the LocalDynamicMetadataProvider at the SP supposed to work like the
> one at the IdP?

The one on SAMLtest does.

> https://wiki.shibboleth.net/confluence/display/SP3/LocalDynamicMetadataProvider
> suggests that yes, except that the files should not carry a ".xml"
> extension, so just the uuids, right?

SHA-1 hashes rather than UUIDs.  I have no idea whether the .xml extension is mandatory, but it is on all the uploads on SAMLtest.

> Then I have two questions: is the
> sourceDirectory relative to /etc/shibboleth?

I use absolute paths, but I would presume so.  Will be corrected if wrong.

> And second, what needs to
> be done to make these metadata show up in the DiscoFeed? Together with
> some students we tried to get this work, to no avail.

I don't think they'll appear in the DiscoFeed along with any of the other dynamic providers, as one of the primary goals was to get away from monolithic files, and much of the dynamic lookup work was done for MDQ.  MDQ is capable of listing all its providers, but it does so itself:

3.2.2.  Request All Entities

   A metadata query request for all entities known to the responder is
   performed by issuing an HTTP GET request to a URL constructed as the
   concatenation of the following components:

   o  The responder's base URL.

   o  The string "entities".

   For example, with a base URL of "http://example.org/mdq/", a query
   for all entities would be performed by an HTTP GET request to the
   following URL:

   http://example.org/mdq/entities

SAMLtest does not display SP's in the DiscoFeed in its present configuration, but it did when it was using one gigantic local aggregate.

Again, some of this is just intuition, but if I'm right, it'd be a neat feature to request.

Take care,
Nate.