managing untrusted metadata

[Cantor, Scott]

> 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?

I have a range of options with various scripts to handle conventional systems like Shibboleth and SSP that have consistent metadata, but I handle all the one-offs manually right now. I would prefer to break them up into individual files, and probably will use LocalDynamic for that. Then there's the Unicon work on a GUI that also handles one-offs well and ends up producing a directory usable with that plugin.

> 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).

Grep? How often do I have to go into the metadata anyway? Hardly ever.

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

Just started, I scripted all of it and used rsync to push it around, it's fine. I have some issues with the code I've already filed bugs on, but for most purposes it's fine if the metadata is relatively static. It needs control over refresh based on the files changing like the SP supports.

> 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.

You're using a different definition of "trust", I treat all the federation metadata as trusted and know that I got it from a reliable source and it hasn't been tampered with. That's all.
 
> 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.

Yes, but they care *nothing* about the Format and so any metadata purporting to claim anything about that is not accurate, to a high degree of certainty.

> 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?

It absolutely tells you the former, that's what it *means*. It does not tell you the latter, which I agree is an issue but to be fair, I care only to some degree for whether the SP breaks itself that way. I care if it handles *my* key rollover. That's what we really have a gap around and that could only be self asserted in the end, or deduced by inference based on the apparent type of software used.

-- Scott