MetadataProvider and update
Brent Putman
putmanb at georgetown.edu
Thu May 11 16:12:17 EDT 2017
On 5/11/17 8:56 AM, Cantor, Scott wrote:
> You almost certainly want to host the signed metadata files individually and serve it up via MDQ and just use the dynamic plugin as Peter said. With the caveat that right now it has a major bug involving the artifact binding if that's a use case, but that's pretty unlikely and you could work around it if necessary.
>
Out of curiosity: If he didn't want to stand up an MDQ server, couldn't
he also just use the new dynamic provider file:// URL support in 2.6?
Maybe there's something about that I'm missing, I haven't actually used yet.
As I have understood it, something like the following would allow to
drop files into a directory and be resolved automatically by shibd on
first use:
<MetadataProvider type="Dynamic">
<Subst hashed="SHA1">file:///path/to/metadata/$entityID.xml</Subst>
</MetadataProvider>
Where the $entityID substitution will be the SHA1 hash of the entityID.
(Question: Is that the lower or upper case hex encoding of the hash? Or
Base64, etc? The docs don't really say).
If on the other hand, it's a cluster of SP's without a shared
filesystem, then of course MDQ would probably be the better approach.
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMetadataProvider#NativeSPMetadataProvider-DynamicMetadataProvider
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170511/a1b494c4/attachment.html>
More information about the users
mailing list