Instant File Sharing using HTML5

I’ve done a proof of concept implementation of a File Sharing web application using HTML5 File API and Drag and Drop API.

The coolest part is that people can start downloading the file, even before the upload is completed.

The implementation is a few lines of code in javascript on the front-end, combined with a small script in Node.js on the server side. Enjoy!

And I wish you a happy christmas as well. Thanks for following my blog!

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 discojuice.org. Installing DiscoJuice is (almost) as simple as including a sniplet like this, into your HTML header section:

<!-- DiscoJuice hosted by UNINETT at discojuice.org -->
<script type="text/javascript" src="https://engine.discojuice.org/discojuice-stable.min.js"></script>
<link rel="stylesheet" type="text/css" href="https://static.discojuice.org/css/discojuice.css" />
<script type="text/javascript">
    DiscoJuice.Hosted.setup(
        "a.signon", "Example Showcase service",
        "https://service.org/saml2/entityid",
        "http://service.org/response.html", ["edugain", "kalmar", "feide"], "http://service.org/login?idp="
    );
</script>

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 discojuice.org. (see Advanced Configuration).

var djc = DiscoJuice.Hosted.getConfig(
    "Demo of local auth",
    "https://example.org/saml2/entityid",
    "http://dev.discojuice.org/discojuice/discojuiceDiscoveryResponse.html", ["edugain"], "http://example.org/login?idp="
);

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',
        'country':'_all_',
        'geo':null,
        'weight':-8
    }
];

Next, we create a HTML form for local authentication:

var localauth = 
    '<form method="post" action="https://example.org/loginlocal"> '+
    '<p>Sign in using account at <strong>example.org</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>' +
    '</form>';

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) {
    console.log(e);

    var auth = e.auth || null;
    var returnto = window.location.href || 'https://foodl.org';
    switch(auth) {

        case 'local':
            DiscoJuice.UI.setScreen(localauth);
            $("input#lu").focus();
        break;

        case 'saml':
        default:
            window.location = 'https://foodl.org/simplesaml/module.php/core/as_login.php?AuthId=saml&ReturnTo=' + escape(returnto) + '&saml:idp=' + escape(e.entityID);
        break;                          

    }
}

And we run DiscoJuice with the configuration above.

$("a.signin").DiscoJuice(djc);

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 discojuice.org

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

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.

Foodle Upcoming

You’ll notice some updates on the Foodle front page today. There is a box called upcoming, showing events and tentative time slots in near future.

This is part of my preparations for offering a serie of cool group-aware OpenSocial Gadgets.

The upcoming stuff will also show up on group pages:

Another feature, probably very useful, is the upcoming iCalendar feed, linked from the front page. Copy the link and choose to subscribe to it from your calendar, instead of downloading it.

Stay tuned for the Gadgets…

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:

Federations on a map

As you know, DiscoJuice is very happy because you are providing Geo Locations in your metadata feed. If you don’t, please do 🙂

Here is a visualization of the Identify Federations based upon geo locations provided in metadata (with some fallbacks):

Data quality is sufficient to be useful, but I hope that the data quality of the metadata sources will improve, giving users a even better user experience.

This map is using data feeds generated by DiscoJuice.org.

DiscoJuice 2.0

I’m preparing a new release of DiscoJuice, version 2.0. This is centrally hosted version, at discojuice.org, and it should be ready today, to start playing with it. All the neccessary components are available, and the documentation should be more or less up to date.

The DiscoJuice engine, is available in to two tracks, stable and dev. These will automatically point to the appropriate version of DiscoJuice. The script is minified, compressed and the hosting supports caching well.

We are automatically generating feeds for most existing Identity Federations, using various techniques for getting the best data quality to feed into DiscoJuice. We support most of the MDUI extension and will make use of information in there. DiscoJuice is now multilingual, and extracts translated names of institutions from the metadata.

Thanks to all of you that helped us get DiscoJuice translated into 15 different languages.

Feel free to have a look at the available generated metadata feeds:

To get started, you probably would like to start here:

Setting up a central IdP Discovery Service for a federation

DiscoJuice also contains an implementation of the IdP Discovery Protocol in javascript, and setting up a full fledged IdP Discovery Service for your federation, is now as easy as copying and pasting a static HTML page to a location of your choice; given that your federation metadata is already available as one of the prepared feeds at discojuice.org.

DiscoJuice and SimpleSAMLphp

There has been a discojuice module in simpleSAMLphp for quite some time, although it has never been part of a stable release. The early version has included a selfcontained version of DiscoJuice. The new version now instead refers to the central hosted discojuice.org.

If you earlier installed simpleSAMLphp just to get DiscoJuice working more easy, that should no longer be necessary. It should be far more easy to setup DiscoJuice now without SimpleSAMLphp.

For those of you that are already using the discojuice module in simplesamlphp, you probably need to carefully consider how to proceed. Feel free to join the mailinglist for discussion the options.

Please give feedback

If things does not work as you expect it to, if you have feature requests, or if you have any questions, please use the discojuice mailinglist.

Presentation at FAM11

DiscoJuice will be presented at eduServ FAM11 http://www.eduserv.org.uk/newsandevents/events/fam11

If you are there, feel free to comment or ask about DiscoJuice.