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

[Ian Young <ian AT iay.org.uk>]

As Peter says, this is not the first time we've had the "why is eduGAIN allowing these particular entities into the aggregate" conversation. In this case because we are again almost certainly talking about UKf entities, I'll respond, but I don't think anything has really changed.

On 16 Apr 2015, at 12:57, Olivier Salaün <olivier.salaun AT renater.fr> wrote:

I noticed that 108 SAML entities in eduGAIN MDS metadata have the hide-from-discovery entity category set.

A high proportion of those are likely to be from the UK federation, given our opt-out stance. I don't think it will be all of them, though, and in general as people move towards opt-out then eduGAIN will end up having more things in it which don't need to be. That's rather different from saying that they need to be *not* present.

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.

As you say, that's a supposition. The entity ID has no attached semantics and I know at least one organization using "dev" to mean "research and development". But the majority of the IdPs in question are probably not production IdPs, I agree, for some definition of "production IdP".

I can also suppose that some of these IdPs allow login with test accounts.

That's another supposition, and perhaps it is true that some of them do allow login with test accounts. There's no evidence either way, though, and moreover there is nothing about eduGAIN in general that guarantees that *any* IdP involved might not have test accounts or be otherwise less thorough than you'd hope it would be.

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

Again, although I can see why you'd like every IdP involved in eduGAIN to match some standard you have in mind for LoA or identity management, as things stand today there is no eduGAIN requirement in this area and no agreed standard. If your SPs make assumptions about IdP behaviour based on the mere ability to see the metadata for an IdP, that's a general problem and not one restricted to these particular IdPs.

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.

It could be, but for that to be reasonable I think we'd all have to:

* agree on a clear standard to apply to which entities MUST NOT be included in metadata exported to eduGAIN

* evaluate the consequences to each federation for excluding those entities, and the cost to participants involved

* change the constitution

* allow enough time for member federations to change their operations to comply. That might be quite a while, as we'd be talking about individually evaluating all entities (in the UKf, more than 1700 evaluations) and then getting entity operators to change their processes to avoid exclusion 

Actually why do federation include such test IdPs in their eduGAIN upstream metadata?

Ignoring the question about whether these are indeed "test IdPs" for some definition of that term, in our case it's simply because we don't see sufficient value in doing the work to exclude them. Well, unless we just excluded any IdP with "dev" or "test" in its entity ID, but in that case although it would be inexpensive to do it might have subsequent costs elsewhere.

Any chance these test IdPs would be removed from upstream eduGAIN metadata?

One route is described above: if the membership feels that eduGAIN needs to be exclusive of a certain category of entities, then we should as a group clearly specify that category of entities and work towards their exclusion. It wouldn't be something that could be done soon, of course, specifications of that kind are very hard to write and even harder to agree and implement.

There are various other half-hearted approaches that might appear to give you what you are looking for but would in fact not do so. For example, we could require opt-in for IdPs which are "hide from discovery". This wouldn't actually give you any more assurance that the entities  that remained would not include any which did not meet your standards for LoA and identity management, so I wouldn't recommend it. It's obviously something we can discuss, though.

    -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature