No metadata returned for SP with matching protocol
Michael A Grady
mgrady at unicon.net
Thu Jan 14 16:34:57 EST 2016
> On Jan 14, 2016, at 12:45 PM, Cantor, Scott <cantor.2 at OSU.EDU> wrote:
>
>> On a slightly related note, am I correct that there's still no way to tell the IDP
>> to load metadata from every file in a directory?
>
> No.
>
>> If this isn't available on the IDP (I've seen that it is on the SP now), I assume
>> there's a good reason for that.
>
> No, there's a half-assed version in the SP. It doesn't monitor the directory so it doesn't see new files or get rid of deleted ones, which IMHO is a requirement and is non-trivial to build.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
One thing I had suggested to one client I was working with awhile back was the idea of maintaining a directory of individual files, but then having a script that read all those files in, checking schema validity etc. and outputting a new "aggregate" from those. (And maybe even checking that was valid before replacing the current local aggregate with the updated one.) I had a very simple Perl script for combining all the files wrapped in EntitiesDescriptor, but hadn't added in executing xmllint or xmlsectool on each separate file, just assumed one would do that before adding a new file to the "aggregate directory". I've seen other places that manage it all in a database, and generate a bunch of individual metadata provider entries from the DB. (I.e. auto-generate a metadata-providers file).
--
Michael A. Grady
IAM Architect, Unicon, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://shibboleth.net/pipermail/users/attachments/20160114/215aeef6/attachment.sig>
More information about the users
mailing list