About opt-in and why it is your fault

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

Metadata distribution

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.

Basic profile

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!

New draft of Kalmar2 Appendix A

This version was circulated monday September 27th 2010, as a proposed update to the existing version of the document

The current official version of this document is available on the http://kalmar2.org web site.

Change log

Here is a list of the most significant changes:

  • Re-written introduction: Publishing entities from local federation to Kalmar
  • SAML 2.0 Web Single Sign-On Profile: added text about SPs in multiple federations.
  • SAML 2.0 Metadata: re-written and modified text on validity period.
  • Important: Added metadata requirements to name and description
  • Added: Attributes in Kalmar
  • Added: Metadata Extensions for Login and Discovery User Interface
  • Added: Monitoring.
  • Extended the section on scopes.
  • Extended the section on Attribute Release Policy.

Kalmar2 is open – after 480 years the Nordic countries join forces again

480 years after the collaps of the first Kalmar Union, the Nordic countries are joining forces again – this time without guns or politics but armed with the latest technology for easing access to services while still protecting the users’ privacy and personal data.

Today Kalmar2, the second Kalmar Union, is presented at the NORDUnet conference in Copenhagen. Users can use their existing usernames and passwords freely across the Nordic area to access protected web-pages like research databases, e-science and e-learning systems etc. Kalmar2 fulfills the need in educational and research sector for collaboration and sharing of resources across borders.

The goal is to strengthen Nordic collaboration, based on existing national infrastructures for role based access.

Knitting together login-systems from all Nordic countries, it is now possible for users to log into web based services using their existing username and password – not the one provided by the website!

Participating countries are Norway, Finland, Denmark, Sweden and Iceland.

Kalmar2 is not confined to the Nordic area. Other countries may join if they live up to Kalmar2’s strict requirements for identity management.

“Kalmar2 is an example of the Nordic area building critical infrastructure for our academic community. Identity infrastructure is at the same stage Internet was 20 years ago, when the Nordic Internet infrastructure was operational across borders. With Kalmar2, the Nordic eScience collaboration and sharing makes a leap forward” says Ingrid Melve, Chief Technical Officer for UNINETT, the Norwegian research network.

The Kalmar2-work was funded by NordForsk

See http://www.kalmar2.org