Shibboleth Developers

[Tom Scavo <>]

On Wed, Feb 25, 2009 at 10:53 AM, Scott Cantor 
<>
 wrote:
> Christopher A Bongaarts wrote on 2009-02-25:
>> In the immortal words of Tom Scavo:
>>> AFAIK Shibboleth has always required metadata to be configured on a
>>> per-file basis.  It would be more convenient (and less error prone)
>>> for deployers if there were a configurable metadata directory  Then
>>> all you have to do is drop a metadata file into the directory and go.
>
> That doesn't really make much sense to me in light of the fact that metadata
> is almost always pulled from a remote location.

And every time you pull in a new one, you have to configure a new
metadata provider and restart the server.

> We don't see any non-toy use
> cases in which people would be explicitly pointing at files anymore, other
> than intra-campus cases where you're managing SP metadata on the IdP host,
> and that's basically one file.

Suppose you managed an IdP that consumed federation metadata and then
some nice bilateral partner comes along.  You end up configuring
another metadata provider and restarting the server.  Once you've done
that a few times, you figure out a workaround is to configure a
more-or-less permanent <md:EntitiesDescriptor> element that you can
add <md:EntityDescriptor> elements to at will.  Of course that works
fine until there's some need to re-wrap some of the existing
<md:EntityDescriptor> elements (for whatever reason) or you join
another federation, which requires a brand new file.

So, if there are no extenuating security considerations, I'd say a
configured *directory* is easier to work with all the way 'round.

Tom