hypothetical per-entity metadata question

Cantor, Scott cantor.2 at osu.edu
Thu Jan 24 12:51:20 EST 2019


On 1/24/19, 12:20 PM, "users on behalf of Jerry Shipman" <users-bounces at shibboleth.net on behalf of jes59 at cornell.edu> wrote:

> I was thinking to switch the order -- first try the MDQ mechanism, and if that fails for whatever reason, look to see if
> there is a file.

That's more or less my plan unless I do nothing at all about it, or decide to just punt and run my own MDQ pipeline. InCommon's would probably have to fail enough to piss me off enough to reach that point. To that end, caching of failed lookups was added to 3.4 so it's nominally possible to do it.

The UK's docs likely date to 3.3 when the lack of failure caching would have caused a lot of extra delays. But failure caching illustrates all the complexity inherent in any of this, there are a dozen settings all interacting in complex ways, and asking for "a simple answer" is an impossibility.

We're talking about deploying DNS and then adding fallbacks for when DNS breaks. What does your system do when DNS breaks? Exactly.

> Does the IdP validate the signature on the metadata when it reads it from a file? or is it important to do that before
> writing the file?

Signature checking in the IdP is a metadata filter. It happens any time a piece of signed metadata gets loaded by the resolver plugin containing that filter.

The subtle issue with filters with both dynamic plugins is that filters run over and over for every individual entity and not just once on a batch.

-- Scott




More information about the users mailing list