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

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

Most of this has already been covered by Alex and Brook, but let me add a 
couple of additional points.

On 5 Feb 2014, at 08:54, Jan Tomášek <jan.tomasek AT cesnet.cz> wrote:

> we have discovered that UK federation republishes all entities from eduGAIN 
> into their metadata:
>       http://metadata.ukfederation.org.uk/ukfederation-metadata.xml

Almost, but not quite true. We do filter out a number of entities (currently 
36) which don't meet our metadata quality checks. For example, if an entity 
has a 1024-bit key, it will not be republished. I'm working on resolving 
these quality issues with the other participant federations but I'm sure you 
can imagine that some of them take a long time... obviously we will 
prioritise work for any entity that we have a specific request for from 
either side.

The intention, though, is certainly to publish all the eduGAIN-sourced 
metadata that we can to all of our members.

> but they are not doing oposite. So entites from UK federation are not being 
> republished into eduGAIN.

Right, we operate an opt-in regime *at this time*.

One reason for this is to avoid swamping other eduGAIN participants with 1600 
entities all at once. There is a lot of software out there that is not very 
tolerant to large metadata aggregates. UK federation members have, of course, 
learned to configure things appropriately.

One day I hope that it will be possible to flip this over and switch to 
opt-out as I think that's the right long term model.

> I think this could confuse users.

Yes, it could. Unfortunately, doing the opposite can *also* confuse users, 
until we reach the point where all metadata from all federations is available 
to all entities. That's probably not going to happen very soon; it may take 
the introduction of per-entity metadata services to enable it.

For now, we believe that the confusion that comes from our current choices 
will be smaller than the confusion that would come from the alternatives. 
This is in our opinion the lesser of two evils, in other words. You could 
argue otherwise, and you might even be proven right in retrospect, but for 
now we believe this is the right approach for us.

> By a short experimenting I've found SP https://www.scran.ac.uk/ which offer 
> login by using CESNET, Univerzita Karlova v Praze, ... IdP but those login 
> will always fail because https://www.scran.ac.uk/ is not being exported 
> into eduGAIN, our IdP doesn't know about https://www.scran.ac.uk/ and 
> refuses login. Poor user, poor IdP admin who has to explain to users.
> 
> Is this intentional or is this a bug?

I'd describe this differently than Brook and Alex: it's not "intentional" but 
it is "expected". It's not a "bug" but it is "undesirable behaviour".

(There *is* a real "bug" in this area, but I'll come back to that.)

The behaviour you see is a predictable consequence of these things:

* Scran have not opted in to inter-federation metadata exchange. If you 
actually want to use their services, you and perhaps we should talk to them 
about doing that. If you're just looking for something to test against, try 
this:

        https://test.ukfederation.org.uk/

* Scran don't have a local discovery service but rely on the UKf's central 
discovery service. This is not what we recommend, but it is probably fairly 
common.

* The UKf's central discovery service doesn't know which IdPs are customers 
of which SPs, so it can't restrict the list... that's why we recommend people 
implement local discovery at the SP. We don't think it's practical for the 
UKf staff to keep track of the relationships between our 886 SPs and 725 IdPs 
(that's 642,350 potential relationships, for those without a calculator 
handy) so we're not going to try.

I said there was a real bug, too. Maja pointed out to me that if you go to 
Scran's SP (and I don't mean to pick on Scran here, but they are the example 
on the table) and then select the Copernicus IdP then you'll get an 
unpleasant NullProtectionException and a stack dump. That's a bug, by 
definition.

This appears to be because the IdP in question does not support SAML 1.1. 
People need to be a bit tolerant when it comes to the UKf in this regard: as 
one of the earlier federations we have a *lot* of SAML 1.x-capable entities 
(99.4% of our IdPs, for example) and a fair number of entities that can 
*only* handle SAML 1. We're working on this, but it's very slow going.

In Scran's case, and this will be true for a number of our SPs, the problem 
is not that they do not support SAML 2.0 as such (they appear to be running 
Shibboleth 2.5.x for their service) but that they use our central discovery 
service via the legacy "WAYF" protocol rather than the more modern "DS" 
protocol, which is SAML version agnostic. This limits them in practice to 
SAML 1.x IdPs, and Maja's IdP only supports SAML 2.0.

We are, I think, likely to see a fair number of these compatibility issues as 
the UKf starts to make real use of eduGAIN, and as we offer more of our 
entities to eduGAIN. Many of them will be fixable by helping the entity in 
question to reconfigure appropriately, and if you come up against a case like 
that you should contact Alex and his team in the first instance:

        service AT ukfederation.org.uk

More general discussions, like this one, are probably best done here or by 
e-mailing me directly.

        -- Ian

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