Skip to Content.
Sympa Menu

edugain-discuss - Re: [eduGAIN-discuss] Test/dev IdPs in eduGAIN metadata

edugain-discuss AT lists.geant.org

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

List archive

Re: [eduGAIN-discuss] Test/dev IdPs in eduGAIN metadata


Chronological Thread 
  • From: Nicole Harris <nicole.harris AT geant.org>
  • To: <edugain-discuss AT geant.net>
  • Subject: Re: [eduGAIN-discuss] Test/dev IdPs in eduGAIN metadata
  • Date: Thu, 16 Apr 2015 15:16:37 +0200
  • Authentication-results: geant.net; dkim=none (message not signed) header.d=none;
  • List-archive: <http://mail.geant.net/pipermail/edugain-discuss/>
  • List-id: "An open discussion list for topics related to the eduGAIN interfederation service." <edugain-discuss.geant.net>

Hi Olivier

On 16/04/2015 13:57, Olivier Salaün wrote:
552FA3B6.204 AT renater.fr"> Hello,

I noticed that 108 SAML entities in eduGAIN MDS metadata have the hide-from-discovery entity category set.
I checked what kind of IdPs have this attribute set and it turns out that most of these IdPs have entityIDs looking like https://idp-test.xx or https://idp-dev.xx. I therefore suppose they are not production IdPs. I can also suppose that some of these IdPs allow login with test accounts.

I don't like the idea of eduGAIN metadata including non production SAML entities, especially IdPs, because it brings a risk of user impersonation for all production SPs. It sounds strange to mix test IdPs with production IdPs while we all talk LoA and try to convince institutions they should improve their identity management processes :-\
552FA3B6.204 AT renater.fr">
Since these IdPs are flagged as "hide-from-discovery" in eduGAIN metadata, I am able to filter them out, but 1) "hide-from-discovery" does not mean "test SAML entity", given the spec <https://refeds.org/category/hide-from-discovery/> and 2) it moves the filtering burden to downstream eduGAIN metadata processing, whereas it could be done by the registering federation.
These tags are exactly intended to support filtering behaviour :-)  There will always be scenarios where federations have a disagreement about whether something is a "valid" entity - and the burden of filtering will always fall with the federation that wants it absent. 

Why would you assume that non-production SAML entities have lesser assurance standards?  if they are published in to metadata then they have met the requirements of the federation in question in these terms.  There are valid reasons for doing this:

 - live testing with the SP before releasing to general users.
 - Moving from Shib 1.3 to 2.x, move from Athens to Shibboleth (big usecase for this in the UK), or any general major move.

There are then the usecases that Tom mentions that have nothing to do with testing such as B2B cases.

The assumption that these have "test" accounts would also be incorrect - again any entity published into metadata has to meet the general standards of the federation in question and in many places this will mean that test accounts are not permitted.  See the pushback against edugain "testing" instances. 
552FA3B6.204 AT renater.fr">

Actually why do federation include such test IdPs in their eduGAIN upstream metadata? Are their real use cases?

Yes, see above.
552FA3B6.204 AT renater.fr">
Any chance these test IdPs would be removed from upstream eduGAIN metadata?
Inclusion in upstream metadata is at the discretion of the operator in question.
552FA3B6.204 AT renater.fr">

Regards.

--


 
Olivier Salaün
Etudes et projets applicatifs
 
Tél : +33 2 23 23 71 27
Fax : +33 2 23 23 71 11
www.renater.fr
RENATER
263 Avenue du Gal Leclerc
35042 Rennes Cedex



-- 
Nicole Harris
Project Development Officer
GÉANT Association Amsterdam Office (formerly TERENA)
Singel 468 D, 1017 AW Amsterdam
The Netherlands
Skype: harrisnv
M:+31 64 610 53 95

Attachment: pngi5I2YKMOLp.png
Description: PNG image




Archive powered by MHonArc 2.6.19.

Top of Page