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:

Live Visualization of Federated sign-on through Feide

This video shows live data of students or teachers logging in through the norwegian Identity Federation Feide. The location of the school from which users login is plotted in real time on the map.

View the video on youtube

The presentation is written in javascript, using HTML5 WebSockets.

Feide also have other ways of visualizing user logins.

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.

Identity Provider Selection UX: Moving selection of Feide institusion to the RP

When a RP offers a wide variety of login options, and Feide is one of them, a two-step Identity Discovery UX will fall natural for the technical architecgture. Multi-step discovery is not optimal, and I’ve done some research in ways to avoid that, and implemented a proof of concept within the DiscoJuice discovery service.

Today, I took the discovery UX showcase live on Foodle. When you now want to login to Foodle, you may select between norwegian institusions (that have subscribed for Foodle) along with institusions from other european countries.

For those of you that are not familiar with the norwegian architecture; an important element here is that the Feide operates a single IdP for all norwegian institusions, and there is a custom UI for selecting which institusion to login with at the IdP.

Foodle now may both read and write preferred organisations on Feide; although a inconsistency worth mentioning here is that if you have already successfully logged in with Feide using a specific organization that preference is stored with a higher priority than what Foodle is allowed to write; meaning that Foodle will not allow you to override that ‘preference’. If you want to test this nontheless; you may delete all your cookies at idp.feide.no to see how it works for other users.

Want to learn more about DiscoJuice? – Join my session at TNC2011, at May 17th.

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!

SimpleSAMLphp Live Statistics Demo Video

Feide has this summer setup a live statistics monitor in our offices. The live statistics monitor shows live updated information such as:

  • Distribution of most used services last 15 minutes.
  • Distribution of institusions that logged in last 15 minutes.
  • Number of logins per minute last 15 minutes
  • Number of logins per minute last 4 hours.
  • Live login log

Click below to see demo video.

Continue reading