Here is a short description of the UNINETT WebApp Park Architecture.
I’m currently working with a web application cloud engine, and this is a teaser of a very simple application running in the engine, representing a kind of an App Store making use of open APIs.
Soon we’ll present more advanced web application demos making use of distributed and highly available cloud storage, cross-federated authentication, privacy controls, SOA gatekeeper, and a whole lot of sparkling OAuth love and magic. We may run into WebDAV, WebFinger, Contact search, Invitation, group exchange with VOOT, notifications, gadgets and a lot more.
Stay tuned for updates.
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.
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.
- The user heads to the portal.
- The user do Identity Provider Discovery at SurfConext.
- The user logs in to the IdP.
- The user performs consent to accept user data is sent from IdP to SurfConext.
- The user can now access the portal, and moves on to a space where the Foodle gadget is installed.
- The user will need to consent that the Foodle Gadget is accessing the OpenSocial context.
- 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.
- Part of the three-legged OAuth dance, first goes IdP Discovery.
- Next the user logs in, most likely this bullet is skipped due to Single Sign-On.
- User needs to consent that attributes are released from the IdP to Foodle.
- Then, the user needs to consent that the Foodle Gadget instance is allowed to access Foodle content on behalf of the current user.
- 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.
- 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.
- The Foodle backend uses a yet to be detirmined protocol to explore the CALdav/iCalendar Free/busy endpoints for each of the group members.
- The Foodle backend retrieves free/busy data using CALDav or similar.
- The Foodle backend responds with free/busy data to the Foodle Gadget.
- 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.
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.
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 is a minimal subset of the group related features of the OpenSocial REST API.
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:
Remote group providers
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:
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.