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

[Leif Johansson <leifj AT sunet.se>]

On 12/05/2013 11:50 AM, Dick Visser wrote:
> 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.
>
> ;-)
>
>
The right approach is to figure out how to merge entities from multiple
sources.