Skip to Content.
Sympa Menu

edugain-discuss - Re: [eduGAIN-discuss] IdPs in multiple federations: not listed on all configured powerdisco tabs

edugain-discuss AT lists.geant.org

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

List archive

Re: [eduGAIN-discuss] IdPs in multiple federations: not listed on all configured powerdisco tabs


Chronological Thread 
  • From: Dick Visser <visser AT terena.org>
  • To: Ian Young <ian AT iay.org.uk>
  • Cc: edugain-discuss AT geant.net
  • Subject: Re: [eduGAIN-discuss] IdPs in multiple federations: not listed on all configured powerdisco tabs
  • Date: Thu, 5 Dec 2013 12:56:51 +0100
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>

On 5 December 2013 12:34, Ian Young <ian AT iay.org.uk> wrote:
>
> On 5 Dec 2013, at 11:14, Peter Schober <peter.schober AT univie.ac.at> wrote:
>
>> While that's not solving the issue why are those EntityDescriptors of
>> your IDP so different? Is that something you could influence/change?
>
> That's an important point. If the problem would go away if every place the
> entity was registered had the same metadata for it, it would be interesting
> to look into why there were differences.

Our IdP has this metadata: https://login.terena.org/idp/saml2/idp/metadata.php

SURFnet publishes a modified version of this in their SURFconext IdP
feed at https://engine.surfconext.nl/authentication/proxy/idps-metadata.

The most important difference is are the endpoints. Ours just go to
the IdP, while SURFnet's copy lists SURFconext.
That copy is also included in Edugain, and now also in UKfed.

> The other possibility I can think of is that one or more of the places the
> entity is registered imposes some sort of constraint such that "their"
> version of the metadata is necessarily different. Things like this can be
> technology-based (e.g., a limitation in a federation's metadata repository)
> or policy-based, but as a first step we should try and identify such
> constraints where they exist. Whether we need to work to remove them
> depends a lot on how quickly we can use eduGAIN to remove the need for
> multiple registration, of course.

Instead of leaving the blacklisting up to the party consumer the metadata
feed.
It would be nice to have metadata URLs accept a
blacklist/do-not-include parameter, so that this this process can be
done centrally.

So instead of requesting http://mds.edugain.org, manually fiddling to
sift our what you don't want, you could request:

http://mds.edugain.org/?exclude=https%3A%2F%2Flogin.terena.org%2Fidp%2Fsaml2%2Fidp%2Fmetadata.php

I remember KALMAR has something similar.

Just an idea.


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





Archive powered by MHonArc 2.6.19.

Top of Page