managing untrusted metadata

[Tom Scavo]

I pulled in some comments made by Scott in another thread. [1] Using
these comments as conversation starters, hopefully we can arrive at a
set of best practices for managing untrusted metadata.

On Fri, Apr 20, 2018 at 11:00 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> I never rely on remote metadata provided by people that have no idea what they're doing (i.e. most vendors).

Well "never" is pretty strong but I get your drift. I suspect most
seasoned IdP deployers have come to the same conclusion, so the
question is how best to manage untrusted metadata, whatever its
source.

My guess is that deployers simply copy a snapshot of the metadata to
the IdP file system and use FilesystemMetadataProvider to load it upon
startup. Is this the best we can do?

Now we have LocalDynamicMetadataProvider but the uses for this new
functionality are not yet clear (to me). Substituting one
LocalDynamicMetadataProvider for N FilesystemMetadataProviders is
enticing but the file names in
LocalDynamicMetadataProvider/@sourceDirectory are opaque and therefore
difficult for a human to identify and manage (or so I think).

To all: If you're using LocalDynamicMetadataProvider today, please
weigh in with your experiences.

Personally, I like the way Peter manages untrusted metadata using git
[2] but he doesn't say how the metadata is ultimately consumed by the
IdP. Maybe he can chime in with more info... (Peter?)

On Wed, Apr 18, 2018 at 11:01 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> I would never pull in a third party metadata source outside of InCommon or another similarly managed source, at least absent other assumptions that I have never seen a vendor meet.

This comment is similar to the previous one but since InCommon is
mentioned, let me ask: How do folks manage specific entities in
federation metadata (InCommon or otherwise) that happen to be
untrusted? As you know, just because an entity is registered by a
federation does not guarantee the metadata can be trusted. Please
share your experiences here.

On Fri, Apr 20, 2018 at 10:53 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> You'll recall I tentatively asked about InCommon supporting [the NameIDFormat element in metadata], but then I realized after asking that it was pointless, no services can know (nor do they care) which Format they'll be getting from any given IdP.

Some services *do* care about NameID. I believe there are a fair
number of services that can't consume SAML Attributes and therefore
they care a lot about NameID, which (to them) is all there is.

In any case, InCommon is an outlier with respect to NameIDFormat,
@WantAssertionsSigned, RequestedAttribute, and a few other metadata
bits, which you'll find throughout eduGAIN metadata. In some cases,
these metadata bits are carefully curated and therefore quite useful,
while in other cases they are not at all curated, mostly useless, and
even counterproductive.

Perhaps the most important element in SP metadata is the KeyDescriptor
element yet the absence or presence of that element does not really
tell the IdP deployer what s/he wants to know: Does the SP support
inbound XML encryption? More importantly, does the SP support seamless
encryption key rollover?

Anyway, my point is: Federation metadata may contain untrusted
entities, in which case, what is the best way to manage them?

Tom

[1] https://marc.info/?t=152388658300001&r=1&w=2&n=30
[2] https://marc.info/?l=shibboleth-users&m=150965483025963&w=2