Metadata precedence on entityID appearing twice in two different feeds.

[Tom Scavo]

On Thu, Oct 16, 2014 at 10:30 PM, Tom Poage <tfpoage at ucdavis.edu> wrote:
> On Oct 16, 2014, at 2:49 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>> On 10/16/14, 5:27 PM, "Tompkins,Charles R" <crt at ufl.edu> wrote:
>>> Is it possible to override which metadata an IdP considers for a given
>>> entityID if it appears in two places or is this just broken?
>>
>> It's considered broken, but the SP supports indicating precedence (first
>> or last) while the IdP leaves it unspecified but in practice uses first.
>> So you should generally load your metadata first, because if nothing else,
>> you control it and can change it on the fly.
>
> We've done that, but more often have done the opposite to get metadata installed and working when there's some sort of administrative delay (on the SP end) registering with the federation. When the SP metadata finally does show up from the federation, it (eventually) overrides the local definition, which we can then remove at our leisure. The configuration ends being a kind of metadata 'sandwich':
>
>   override metadata
>   federation metadata
>   fallback metadata

Yes, there are good reasons to take that stance. Let me tell a couple
of stories, both of which are very recent.

A vendor recently joined InCommon as a Sponsored Partner. The day they
introduced metadata into the InCommon metadata aggregate,
interoperability with a number of IdP partners stopped. (Not all IdP
partners, just some IdPs, which was confusing at first.) After doing
some investigating, we determined that the metadata the vendor had
previously shared with each individual IdP had the same entityID but
different endpoint locations specific to the IdP. The metadata
submitted to InCommon was similar: it had the same entityID but
contained new endpoint locations, for a specific IdP.

After reading this thread, you can probably guess what happened. The
IdPs that listed the vendor's metadata first did not stop working
while the IdPs that listed InCommon metadata first *did* stop working.
However, all of the IdP configurations were broken (having been
configured with broken metadata in the first place). The IdPs that
stopped working are no longer broken (or at least they're aware of the
problem). The IdPs that did not stop working are *still* broken, it's
just a matter of time before something stops working.

The solution of course is for the vendor to distribute correct
metadata. Two entity descriptors with the same entityID MUST contain
the same keys and endpoints, at minimum.

A similar situation occurred just last week at the international
level. A vendor is known to publish metadata in 17 federations
(including InCommon). All of the entity descriptors have the same
entityID but different endpoint locations specific to the federation.
Same issue as above.

When one of the federations exported their version of the vendor's
metadata to eduGAIN, it was imported by other federations. Depending
on how the other federations implemented their import process, things
began to break. Those federations that filter existing entityIDs
experienced no breakage. However, there's no interfederation in that
case either.

Federations are scrambling to be the first to export a particular
entity descriptor to eduGAIN (first come, first served). In their
haste to win the race, mistakes will be made, as above. Each
federation that imports eduGAIN metadata will have to filter existing
entityIDs, otherwise things will stop working, but if federations have
to filter metadata, interfederation will fail as an exercise.

Tom