Nicole Harris criticizes the Opt-In model in eduGAIN in her article “So, how does that work?”. I completely agree with most of her points – but these problems goes deeper than eduGAIN — and here follows a challenge back at UK…
What can Inter-federation Do For You?
An important basic principle of Inter-federations, is that it doesn’t add much new functionality – it extends functionality – spatially :). Inter-federations will not solve issues in local federations. Inter-federations only connect the common functionality that overlaps, making it work on a inter-federation scale.
The Scalability Issue
Even though a feature or a workflow is available in two federations, and work perfectly fine in local context — if they do not scale, they do not scale — and hence may not work at all in inter-federation scale.
What functionality is needed
Maybe a bit simplified, but if we want a smooth operation of Federations and Inter-Federations, from the IdP and SPs perspective, these functionalities and work flows needs to be in place:
- Metadata distribution
- Basic Policy
- SAML Deployment Profile
- Attribute harmonization and Attribute Release Policy
- Peer Connectivity Handshake
The technical base layer that needs to be in place before anything work, is two entities to have exchanged metadata. To make this scale, it needs to be done automatically. Most federations has this in place. The «automatic» part is missing in some federation, often in federations built on a hub-and-spoke model.
Before any entities would like to connect to each other in anything but test environments, there needs to be some business agreement. Most federations do support that, and makes it scalable by doing a contract between the federation and the entity instead of the entities with each other.
SAML Deployment Profile
Most federations does not have a clue about this mine field, because they are entirely based upon the Shibboleth software. Shibboleth works very well — with Shibboleth…
There is probably not a single product that follows the SAML specification 100% (this is not entirely taken out of the blue). Even if products follows the specification, there is an very high risk that two deployments has interoperability issues, unless several aspects of the configuration is agreed upon and tested in advance.
Who will encounter interoperability problems between entities? — not the federation, not the Service Provider, not the Identity Provider — but the end user. Most federated application together with SAML software have really poor user experience when an SAML-related error occur.
CC: Flickr, Frerieke
Attribute harmonization and Attribute Release Policy
Attribute harmonization is to some extent handled by eduPerson and SHAC. If you represent a federation, you probably think the harmonization is fairly ok. If you are a Service Provider (I am) to a bunch of European federations, you probably know better.
Attribute Release Policy is much simpler. Still, only a small subset of federations have that in place. Feide, Wayf, Haka (and may be some more) has that.
Those that do not have that in place, such as UK Access Federation (correct me if I am wrong), requires SP admins to make phone calls to IdP administrators to request attribute release. It does not scale very well in a local federation, and it simply do not work at Inter-federation context.
Automated Attribute Release gives the federation the responsibility to quality assure the requested attribute release requests from Service Providers, and Identity Providers blindly follows the decisions made by the Federation.
Peer Connectivity Handshake
Even if an SP and an IdP got metadata right, share a policy, deployment profile, harmonized attributes, and got everything they need to be able to talk to each other, it is not necessarily the case that they both want to. Some Service Providers wants payment for content access, others are only relevant to a subset of the IdPs.
What I call peer connectivity handshake (got any better name?) is the process of a Service Provider to express which IdPs it wants to connect to; and for the IdPs to express that they accept connectivity.
Summarized: The information about which IdPs each SP accepts, and which SP each IdP accepts.
My understanding is that vey few federation has this in place. I’m not aware of any but Feide, but probably there are some.
Opt-In or Opt-Out
If you interpret «Opt-Out» as «everything works unless you manually tell it not to work», that is not an option if you do not have all the functionalities and work flows automated as mentioned in the previous section.
If you got a bunch of federations with missing work flows, you really should not expect the Inter-federation to help you with that. Each federation would need to prepare the workflows locally, then Inter-Federations may help interconnecting it.
Simply because things will not work out of the box unless you got all these; the «opt-in» part is representing letting each entity take care of the manual work flows and functionality that the local federation does not yet offer a solution to.
When the «Opt-Out» model have been discussed in eduGAIN, it has been interpreted as «we will distribute your metadata even if we know you want be able to connect to anyone before you do some manual steps».
eduGAIN, the European Inter-Federation that you definitively will hear more about next months does support metadata distribution using centralized metadata aggregation. The central component is named MDS (Meta Data Service).
eduGAIN have done great work defining a common lightweight policy attached to eduGAIN.
eduGAIN does specify in detail how participating entities should be configured, and how they should act, increasing the chance of interoperability, trough the use of the saml2int profile.
It is not reasonable to expect eduGAIN to fix local federation work flows. eduGAIN will not scale well, and will not be smooth in the first round – but eduGAIN is not to blame for it. eduGAIN v1.0 will be an important step in the evolution of inter-federation. Local federations’ willingness and enthusiasm for improving scalability in local federation work flows sets the bar for the second round.
The Kalmar Union
The Kalmar Union is an operational Inter-federation, that connects together Norway, Sweden, Denmark, Finland and Iceland.
Kalmar uses the same model for metadata distribution, got a policy, and relies on saml2int as well. But in addition, the Kalmar Union supports automatic attribute policy release.
The Kalmar Union got sufficient functionality and work flow in place to start thinking of Opt-Out. In fact, parts of Kalmar is already supporting Opt-Out. That goes for most of the Identity Providers.
This means that a Service Provider connecting to Kalmar would more or less automatically get things working with all nordic Identity Providers – without doing phone calls.
But PEER fixes everything, right?
There is a lot of fuzz around PEER. PEER does not solve any of the concerns mentioned above. PEER is a third party registry for metadata.
PEER may end up delaying Inter-Federations, like NAT delayed IPv6. Or it may result in a lot of good harmonization work on metadata content, extensions and usage; that actually accellerate and simplify the process of implementing Inter-Federations like eduGAIN. Time will show!