Skip to Content.

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: Kristof Bajnok <bajnokk AT niif.hu>
  • To: Olivier Salaün <olivier.salaun AT renater.fr>, "edugain-discuss AT geant.net" <edugain-discuss AT geant.net>
  • Subject: Re: [eduGAIN-discuss] Test/dev IdPs in eduGAIN metadata
  • Date: Fri, 17 Apr 2015 07:22:20 +0200
  • 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>
  • Organization: NIIF Institute

Hi Olivier,

On 2015-04-16 13:57, Olivier Salaün wrote:
> 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.

As others have already pointed out, it's a wrong deduction chain. I can
only confirm that it's also not true for Hungarian entities. All test
IdPs I've ever came across during our production federation lifetime
were relying on the institutions' production IdM systems. So if there
were test accounts in the test IdP, they would be present in the
production one as well.

Even (prod) NIIF IdP has at least one test account for Icinga checks.

> 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 :-\

I think your real concern is that there are identities that are not
traceable to a real person. (Probably 'trace' is not the suitable word.)
There might be an expectation in most of us that if any abuse occurs, we
can inform the IdP who can find the responsible person for the identity.
At least the one who lost his password, thus it is possible to
1) have someone to blame;
2) make an end to the abuse.

I don't know if this expectation holds in real life, but I can imagine
that if it turns out to be false, it would create a hubbub here or there.

In our policy we try to address this in a way that we require all test
accounts to be documented along with the individual who is responsible
for the test account. We have no means to enforce it but we have some
text to point at. At least we could have someone to blame. ;)

Kristof





Archive powered by MHonArc 2.6.19.

Top of Page