Skip to Content.

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: Peter Schober <peter.schober AT univie.ac.at>
  • To: 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:14:27 +0100
  • Authentication-results: prod-mail.geant.net (amavisd-new); dkim=pass header.i= AT univie.ac.at
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>
  • Organization: ACOnet

Leif's short comment said it all. I'll just add a bit of -v

* Dick Visser <visser AT terena.org> [2013-12-05 11:51]:
> 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.

While that's not solving the issue why are those EntityDescriptors of
your IDP so different? Is that something you could influence/change?

Also maybe some of the federations you're peering with bilaterally do
(or could, on request) also offer a feed for you that does not contain
interfederated entities but only those registered by the federation
itself.

Jfyi, in a somewhat similar case (bilateral peering plus now eduGAIN;
we cannot yet remove the bilateral peering since most institutions are
not yet exported via eduGAIN and would hence lose access to the
service) an SP was unable to deduplicate multiple identical entities
(at least the EntityDescriptors were identical, so picking any one
would work) and IDPs were shown several times.
I hacked around this issue by generating yet another metadata feed for
the SP, containing all the IDPs we registered MINUS the ones we expose
via eduGAIN/interfederation. So the service will get our
eduGAIN-exported IDPs via eduGAIN, and only the "rest" via the
bilateral feed. I can now reuse that feed with other SPs, if required.

> 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.

That seems to be a problem unique to H&S federations trying to offer
this as an additional service (which IdP can connect to which SP).

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

Using pyff as aggregator I always prefer my own copy of entities over
those I recieve from others (exactly for the case of duplicate
entities).
-peter





Archive powered by MHonArc 2.6.19.

Top of Page