Technical details on how DiscoJuice works

There are several roles of the play of DiscoJuice, each falls into separate same-origin policies. (not all the domain names are not real, but used as an example)

  • The web service provider, that needs to know which provider to login the user;
  • The DiscoJuice static content, including the script, some UI elements, such as images and css; provided from
  • DiscoJuice JSON Metadata feeds, a compact optimized metadata document for federations using JSON;
  • An IP to geo JSONP lookup service; running on
  • One or more existing discovery services;
  • A new central passive discovery service;

Installing DiscoJuice

The web service, includes in the web template of the service at a script element referring to the static DiscoJuice javascript running at

Also the web service includes a response.html page at This is used to receive responses from IdP Discovery Services.

DiscoJuice Operations

When a user clicks a login button or otherwise invokes DiscoJuice. The browser loads the script from, but runs in the context of The script draws the core UI of DiscoJuice on the screen, embedded in the web page running on The CSS and images are loaded from

Now, DiscoJuice loads one or more metadata feeds using JSONP from also caches provider logos adjusted to an appropriate size (approx 40x60px). On an engine runs to generate JSON metadata from SAML 2.0 Metadata, and postprocessing logos etc.

In parallell, the uses the JSONP interface of to get the estimated geo-location of the current user, based upon lookup of IP address. This is used to preselect the country in the UI, and as a fallback geo-location of the user used to sort the entities based upon distance.

Then DiscoJuice if configured make passive IdP Discovery Requests to a set of configured Discovery Services. These requests is compatible with all existing WAYFs or Discovery Services, by using the IdP Discovery Protocol. The user is not redirected, instead the scripts load a hidden iframe within the body of the web service. The iframe’s src points to the IdP Discovery endpoint at the discovery service endpoint of a remote discovery service. The return parameter to these iframe URLs are pointing back to the response.html running on These requests are made to check if the user has preselected any provider in any of the remote discovery services. Obviously these requests are made passive and does not always return any result, but never involves UI. The iframe content is redirected back to the response.html page with the selected provider as a query string parameter. The response.html page has a inline script that parses the response from the IdP Discovery protocol, and sends this to the parent frame (this run in the same-origin), DiscoJuice main script receives this and adjust the list of providers.

When the user has selected a provider, DiscoJuice can store use a simple addition to the IdP Discovery Protocol to be able to set the value of the selected provider on a remote domain; such as DiscoJuice includes a hidden iframe similar to the approach above, but with a providerID set in the request. DiscoJuice has two implementation of an extended version of the Discovery Protocol, a server-side and a client-side implementation. The servier-side implementation typically uses cookies to store the selected provided in the context of A client side implementation can use cookies or localStorage. uses access control to only leak preferred providers to clients registered in metadata, using the already established elements for that in SAML 2.0 metadata.

As a result the preferred provider is always shown on top of the list, even when the user moves between service providers running in completely separate domains. DiscoJuice achieve this even though the DiscoJuice script runs in the local context of the service provider.

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:

Complicated Flows, OpenSocial, OpenID Connect, Discovery and Consent

I’m currently working on some projects involving a bit more complicated “flows”, than I’m used to.

We’re used to work with Identity Providers communicating with Service Providers, and that’s more or less it. What we will see, is service providers communicating with each others, and consumers retrieving information from multiple sources.

OAuth will play a significant role in this new game.

I believe our challenges and headaches are moved from complex protocols and simple flows, to maintaining a simple and intuitive user experience with simple protocols, but much more complex architectures and flows.

Here is an example that I’m currently struggling with;

We will create a Foodle OpenSocial Gadget that runs inside the SurfConext OpenSocial Container, to present an aggregated free/busy information with availability information for when members of the current group context is available for a meeting.

Here is how it will work (by default). Worth mentioning, this is the worth case scenario, much of the consent and choices are remembered for subsequent flows.

Foodle offers a Gadget, installed in a space in the SurfConext portal.

  1. The user heads to the portal.
  2. The user do Identity Provider Discovery at SurfConext.
  3. The user logs in to the IdP.
  4. The user performs consent to accept user data is sent from IdP to SurfConext.
  5. The user can now access the portal, and moves on to a space where the Foodle gadget is installed.
  6. The user will need to consent that the Foodle Gadget is accessing the OpenSocial context.
  7. The Foodle Gadget would need to establish a trusted connection with the Foodle Backend using the Foodle third-party REST API, starting the three-legged OAuth dance. This will involve a popup window.
  8. Part of the three-legged OAuth dance, first goes IdP Discovery.
  9. Next the user logs in, most likely this bullet is skipped due to Single Sign-On.
  10. User needs to consent that attributes are released from the IdP to Foodle.
  11. Then, the user needs to consent that the Foodle Gadget instance is allowed to access Foodle content on behalf of the current user.
  12. Now, the Gadget has established a trusted connection to the Foodle backend, the Foodle Gadget has access to the group context through the OpenSocial javascript API, but yet, the Foodle backend does not have access to the group context. To allow that, the Foodle backend would need to do a three-legged Oauth dance with the SurfConext Container OpenSocial REST API. And to start that the backend would need control of the user, so the Gadget has to somehow do a popup window (again).
  13. Part of the three-legged OAuth dance, the user has to consent that the Foodle Backend can access the OpenSocial conext (including group info) at the SurfConext portal OpenSocial REST API.
  14. Now, the Foodle Gadget performs a protected OAuth call to the Foodle Backend through the OpenSocial Javascript API, for the free/busy data. In the request body, the current group context is included.
  15. The Foodle Backend performs a protected Oauth call to the OpenSocial REST API to get the group members of the current group, and verifies that the current user is member of the group.
  16. The Foodle backend uses a yet to be detirmined protocol to explore the CALdav/iCalendar Free/busy endpoints for each of the group members.
  17. The Foodle backend retrieves free/busy data using CALDav or similar.
  18. The Foodle backend responds with free/busy data to the Foodle Gadget.
  19. The Foodle gadget displays the data to the end user.

This will result in an unacceptable user experience. Involving popups, and no less than 5 consent screens and two IdP discoveries.

There are tons of approaches to optimize this particular use case, but I’m more interested in the more generic solutions to the flow of this and similar integrations. So that’s one of the many things I’m thinking about these days.

Aggregated free busy is already implemented last year as one of the group-aware features on Foodle – read more…

One thought; I’ve earlier thought of the main motivation to replace SAML with OpenID Connect, would be the simpler protocol, but I’m tending to say that a simpler flow of future use cases would be the best selling point of OpenID Connect.

Identity Federations Status Report – January 2012

GÉANT Identity Federations currently have a lot of ongoing activities. Here is a summary of what we are working on, and the current status.

Federation Lab › Test Federation


allow new SPs and IdPs to easily connect to a set of available entities that are available with no contract neccessary. Self-maintained.

Activity expected to be done April 2012.

Miro: Nothing to update.

Federation Lab › Monitoring and statistics

Miro: As I promised we’ve done preparations for using f-ticks with SSP in production in our federation. I’ll be able to report on that next month.

Federation Lab › SAMLtracer

A significant patch reveiced from Mark Dubrovnic. Some of the patches incorporated, some left. Including UI updates, and support for import export.

Some planned features: Notifications of SAML artifacts, support for IdP Discovery protocol.

Federation Lab › OpenID Connect

We’re making progress. In Februrary we’ll be able to connect the front-end test run UI with the backend test tool, and present to visible results.

There is an interop event in San Fransisco, then a new OpenID Connect meeting in Paris next to IETF. Roland is attending to IETF + Kantara meeting. Andreas might as well. We will have some demo available before that.

The backend test tool is able to produce test results for the initial simple test cases, it is tested against several OpenID Connect Provider implementations.

We’re planning on preparing test fascility for OAuth 2.0 in addition to OpenID Connect. That tool might be very useful for the VOOT work.

RedIRIS will perform an implementation of OpenID Connect that will be coordinated with the test fascility. RedIRIS already have experience and a library for Oauth 2.0, and will make use of that. They will also make an simpleSAMLphp module to make it very easy for enabling OpenID Connect support in an existing IdP or SP running SSP.


Leif: Setup and prepared a drafted IETF templated spec.

Foodle: no updates.

UNINETT has implemented OAuth 2.0, and tested against Leifs implementation. Some problems, but we made it work. OAuth 2.0 support will be integrated into Foodle, this spring.

SurfNet: Ready to exchange OAuth keys with Foodle, is ready to also consume groups from Foodle as a client. Will implement OAuth 2.0 in second half of 2012.

Renater: Has already completed sympa VOOT OAuth 1.0 based implementation. OAuth 1.0 based implementation is made publicly available. Prepared to test against Foodle and SurfNet. Working on OAuth 2.0. Exepcted to be ready March 2012.


The SAML2int profile is being transferred to Kantara Initiative: Federation Interoperability WG.

Scot is will apply some minimal changes contribued by Ian Young.

Federated Provisioning

Mads Freek have been hired by Wayf to work on – mostly – Stinus.

Stinus is the ‘Federated provisioning and de-­provisioning’ project originally proposed by WAYF, SURFnet & JANET as per the enclosed pdf.

A description – one month old – of the architecture is available here:

I expect to have a pre-poc up an running in week 6 and expect to update the description to reflect some recent changes – mostly the use of Gearman both inside core and as the protocol between Stinus components.

Working prototype within 2 weeks.

Wayf will ensure comatibility with connectors used from the Sun provisioning Framework, that also used in Netherlands. Wayf and SurfNet is in dialogue.

Remco has already done some work on Federated Provisioning, will also do much work in the year to come, but it will be funded by another project. Remco will share a deliverable related to the work on the mailinglist.


No updates.


Technology is settling down, more mature, and spec.

Most activity on supporting customers on piloting activities.

Piloting activities around these areas:

  1. Classic e-Science fascilities. SSH access, visitors with physical access to console.
  2. UK National Grid Services.
  3. Cancer Research UK: for microsoft exchange, file sharing, etc. Large organization, divded into 5 institutes.
  4. UK National Health Services. Interested in starting piloting.

Likely initial most important use case: federated login to regular desktops (between different, unrelated MS Active Directory domains), not just applications

Other topics

  • Hot topic: GEANT 3+
  • Convention in Madrid for activity leaders, 27th February.
    • Trained on methodology for GN3+ methodology.

Next meeting in the beginning of March

DiscoJuice and the Identity Discovery Problem

I wrote this article for the:

From the early days of Identity Federations, end-users had to be asked; where do you want to login – or Where Are You From (WAYF). As the federations grew, the WAYF provider drop-down lists exploded.

Federations, such as the UK Access Federation, will continue to grow, and the user experience will get even worse with the current model of selecting provider by browsing through a drop-down list. These days federations are also interconnecting to each other, through eduGAIN, Kalmar2, OIX or similar, making the user experience even worse. Not only by making the list longer, but some of these interconnections make use of bridges, which often leads to nested discovery services, all with a different look and feel.

Multi-step discovery services are also common in the UK, for a number of reasons.

The discovery process of federated authentication cannot be bypassed, the user has to perform the selection every time the user goes to a federated service.

Let me introduce DiscoJuice. DiscoJuice is a very flexible IdP Discovery Service, that focus on improving the usability, and aims to scale to very large lists of providers.

DiscoJuice allows providers to have a single login button, and provide all kind of options to the user within the DiscoJuice interface.

DiscoJuice uses logos for easier recognition of the provider. But never the logo alone, but always together with the name of the institution.

DiscoJuice detects which country you are in, and estimates your location, and sort providers according to distance – starting with the nearby ones first. DiscoJuice may also use HTML 5 geo-location API to improve the accuracy of your location using other techniques.

By showing nearby providers first, often users may find the right entry immediately, and click to login in.

In cases where the user’s preferred provider is not listed on the top, the user may use the incremental search.

DiscoJuice does not only search in the name of the institution, but also the description and keywords.

In UK, several schools or institutions are hidden behind a common login provider (where the institution has no association with the school names). One example that I find, was the SWGfL Merlin provider. DiscoJuice allows you to associate a bunch of school names behind the same login provider, to make it appear when the user performs a relevant search.

When the user has chosen the provider the first time, DiscoJuice remembers the preference, and always show the preferred provider on the top of the list – even when you’re on vacation.

DiscoJuice runs in a hosted environment at Installing DiscoJuice is (almost) as simple as including a sniplet like this, into your HTML header section:

<!-- DiscoJuice hosted by UNINETT at -->
<script type="text/javascript" src=""></script>
<link rel="stylesheet" type="text/css" href="" />
<script type="text/javascript">
        "a.signon", "Example Showcase service",
        "", ["edugain", "kalmar", "feide"], ""

Head over to the documentation for more details.

Combining DiscoJuice with local authentication

The typical configuration of DiscoJuice is to use it as a way of selecting which of a number of external login providers to use.

Sometimes a service would like to combine this with local user/password dialog authentication for some of the users.

Let’s walk through the configuration of a such setup:

Let’s start by getting a configuration object for the DiscoJuice hosted at (see Advanced Configuration).

var djc = DiscoJuice.Hosted.getConfig(
    "Demo of local auth",
    "", ["edugain"], ""

Let’s use the inlinemetadata entry to add a entry for the option of authenticating locally. The entityID does not really matter, but MUST be set to something unique. We also need to set the auth value to something that we can catch in the callback later on. We use the value local.

djc.inlinemetadata = [
        'entityID': 'local://',
        'auth': 'local',
        'title': 'Local authentication',

Next, we create a HTML form for local authentication:

var localauth = 
    '<form method="post" action=""> '+
    '<p>Sign in using account at <strong></strong>.</p>' +
    '<p style="margin: 5px; color: #888" ><input type="text" name="Name" style="font-size: 160%; width: 100%" id="lu" /> <label for="lu">Username</label></p>' +
    '<p style="margin: 5px; color: #888" ><input type="password" name="Name" style="font-size: 160%; width: 100%" id="lp" /> <label for="lp">Password</label></p>' +
    '<p  style="" ><input type="submit" style="margin: 20px 2px" name="smt"value="Login »" /></p>' +

Now, the important part, we define the callback to do a special catch on the local authentication type, and to present the local login form in DiscoJuice:

djc.callback = function(e) {

    var auth = e.auth || null;
    var returnto = window.location.href || '';
    switch(auth) {

        case 'local':

        case 'saml':
            window.location = '' + escape(returnto) + '&saml:idp=' + escape(e.entityID);


And we run DiscoJuice with the configuration above.


Now, local authentication will show up together with the other alternatives:

When the user selects this, the login form is shown inline in DiscoJuice.

Foodle is making use of

I’ve done a major update on the discovery process at Foodle. Foodle now makes use of the hosted version of DiscoJuice at

Foodle both make use of the embedded DiscoJuice popup associated with the login button, and also with a stand-alone page that implements the IdP Discovery Service protocol.

At the same time I did performance tuning of the web server running Foodle. This involves cache header tuning, parallell connections and compression.