Federated OAuth 2.0 SAML VOOT Chat Proof of Concept

Today I’m demoing a proof of concept chat service making use of federated Login and cross-federated group exchange with the VOOT protocol. The chat application is written in Javascript, and is making use of HTML5 WebSockets for Real time communication. The server side is running on Node.js.

The javascript client is using OAuth 2.0 implicit grant with the JSO library we recently released. The user access token is requested with a specific scope for having access to groups. The access token is cahced in localstorage, and send to the chat server during the first registration message. The VOOT provider is done using a new PHP OAuth 2.0 library we have not released yet. It supports using MongoDB and Mysql for storage.

This is only a simple demo of what cross-federated real-time collaboration software can be like. Next step could be adding WebRCT video or audio, file, slide sharing etc.

See also:

VOOT in real life – Federated Groups Proof of Concept

VOOT is a protocol for federated collaboration groups. It allows one service, such as Foodle, to make use of groups of people from a remote group providers, such as SurfNET’s SURFconext.

VOOT is a minimal subset of the group related features of the OpenSocial REST API.

VOOT is hearby proven to work in real life. Actually, Foodle is now connected with SURFconext, and here is a walkthrough of how it all works.

Foodle have a concept of groups; each group have a separate overvidew page listing all Foodles associated with the group, but also calendar availability for the group participants, list of the participants and also file sharing. A group page looks like this:

All users of Foodle may setup and manage their own groups. Here is how the group administration looks like:

This has all been part of the stable Foodle release running foodl.org for quite some time.

Remote group providers

What is new, is that instead of managing the groups within Foodle, you may now hook up to remote group providers using VOOT.

Here is the UI for that:

When connecting to SURFconext, we’re sent to the SURFconext platform, and we’re authenticated over there as well. Single Sign-On makes this user experience not that bad. We need to accept toward SURFconext that Foodle from now on may access your group memberships – this is a one time consent operation.

That’s it. Now we’re connected.

Behind the scene, Foodle have now a cached access token associated with your federated user account. It can keep track of a bunch of access tokens, each for one of the configured remote group providers that you have connected to.

We’re heading over to Surf Teams to manage some groups, and we setup a new group GEANT VO team.

Notice, here is a group of people including people from more than one federation! GÉANT eduGAIN to the rescue.

We’re heading back to the Foodle front page.

Yay! GEANT VO team, a group that is hosted remotely shows up along with all the other local groups! The group is not provisioned to Foodle in some batch operation (as you’re used to hear about from other projects). Foodle does live queries against SURFconext, keeping no local shadow object, but a direct reference to SURFconext.

And, now let’s see what we can use that group for. First, let’s head over to the group page:

The member list is retrieved from SURFconext with Display Names and email addresses. Foodles may be associated with this remote group, and file sharing is aware of remote groups as well.

When creating new Foodle’s you may choose to add that Foodle to a group page, and as you see remote groups are listed together with the local ones:

UNINETT – the first to officially join eduGAIN

UNINETT has now officially joined eduGAIN. There are several countries that are in the process of joining eduGAIN; signing the declaration, tweaking local federation workflow and preparing metadata feeds. UNINETT was the first to get everything ready, and are proud to be green on the eduGAIN map.

We’re looking forward to see more countries joining eduGAIN, and are very happy about all the posibilities that now opens up for norwegian users, institutions and services.

Aggregated FreeBusy Across Domains. Check.

These days we’re working on a cross-domain group protocol. Currently under the nick-name VOOT.

Foodle is one of the showcase applications for cross-domain groups, and we’re adding a few group releated features to Foodle to show how cross-domain groups can be useful.

I’ve also spend some time working on calendaring; and obviously scheduling things are one of the core features of Foodle, so we added a aggregated freebusy view for cross-domain groups.

Here it is:

The screenshot above shows you a group (eduGAIN) that can be accessed in any application supporting VOOT, and the view shows freebusy information from people from 6 different organisations, each with it owns calendar systems.

The default resolution is looking for 1 hour time slots of availability, but this can be set by the user. Here is a view where we look for 5 hours consecutive availability:

In the group management view, we’ve included a freebusy icon showing the current freebusy status of the group participants. Here from the UNINETT group (automatically populated based upon attributes from the federation):

Freebusy feed information has mostly been autoconfigured based on a template system per organisation – the intension is that the user should not really have to deal with that.

That said, the user may very well setup his/her own calendar feeds – people often have private and custom calendars.

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!