An open discussion list for topics related to the eduGAIN interfederation service.

[Dick Visser <visser AT terena.org>]

On 1 February 2011 11:25, Olav Morken <olav.morken AT uninett.no> wrote:

>> Basically an extra array layer.
>
> Unfortunately, that layer would be difficult to use during
> authentication, since we would have no idea about which of the entries
> should be used. Our only option would be to assume that the first
> one is correct.
>
> I think we will always have problems with the same entity arriving from
> multiple sources, and the question isn't only whether we should merge
> them, but also how. Due to differences in federation policies, we
> cannot assume that the contents of them is the same. For example, one
> could use a HTTP-Artifact for the AssertionConsumerService, while the
> other uses HTTP-POST. If both of them have isDefault="true", which one
> should we choose?

[Sorry for crossposting, and also: techno-babble warning]

This issue has bitten me again ;-)
We consume metadata from various federations, several of them
including our own IdP.
Some of those include Edugain, which uses metadata that we supply to
SURFfederatie/conext.
The entityID of the metadata is the same, unfortunately the endpoints are not.
To add insult to injury, the display IS the same, so there is no
visual clue for users that something is off.

UKfederation started to include eduGain metadata, so our own IdP
started to come in through UKfederation.
When trying to log in to our services via the "TERENA Secretariat"
tab, users were presented with a warning from SURFfederatie.
The SP in question wasn't in the list of allow services for the IdP.

I managed to fix this by blacklisting our own IdP entityID for the
ukfederation entry in the metarefresh module.

This has happened before, so I guess I'm better off by blacklisting it
in every metadata source.
This would prevent the same thing from happening when some federation
that we're member of at some point in the future starts to include our
own IdP.

;-)


-- 
Dick Visser
System & Networking Engineer
TERENA Secretariat
Singel 468 D, 1017 AW Amsterdam
The Netherlands