Dataporten.no, an advanced API Platform for education and research in Norway, based upon OAuth 2.0 and OpenID Connect is going live!

Making education in Norway a more interesting market for targeting digital services

Today, any developer or service provider may use the free of charge, 100% self service, developer dashboard to register OAuth 2.0 and OpenID Connect clients. The service provider may choose to enable various authentication backends, such as Feide, ID-porten, Facebook, LinkedIn, Twitter and Feide guest OpenIdP.

Continue reading

Announcing online JWT Debugger tool

JSON Web Token (JWT) is a really nice IETF spec for encoding, signing and encrypting a set of claims using JSON. JWT is a standalone spec that is already used several places, but is also an essential part of the emerging OpenID Connect.

Today I’m anonuncing a online JWT debugger tool that allows you to decode and encode JWTs. This tool is part of the Federation Lab test and debugging suite for identity protocols. The Federation Lab also contains testing tools for OpenID Connect and SAML.

This is considered a beta version, and I’ve not quality controlled the output. The tool is also currently limited to the HS256 algoritm, but if people like the tool we may add more algoritms. Please give feedback if the tool does not work as expected or you have feature requests.

OpenID Connect Test Facility Preview Available

We’re happy to announce that today we’re making a technology preview of the OpenID Connect Test Facility publicly available.

Start right away to test your OpenID Connect Provider:

This is an early preview of a pretty complex set of software, so we’re asking you to be patient, and please report to us any issues. You can do that by posting to our github issue tracker or email me directly.

This test facility has been made possible by myself and Roland Hedberg, an effort as part of the GÉANT Identity Federation project in collaboration with the Kantara Initiative and the OpenID Community.

Here is a video demo of how it all works:

Releasing an OAuth 2.0 Javascript Library

In case anyone find it useful, here is a new OAuth 2.0 javascript library.

It would be useful for me if people tested it and reported any problems. I have limited access to alternative OAuth 2.0 provider implementations, so I’ve only tested a few of the commercial ones so far.

Some use cases, where I think this is useful:

  • given an API with CORS support.
  • in native web apps running in example phone gap, running in file:// context and are thereby not limited by same-origin.
  • in situations where you bypass the token to your own proxying webserver, but would like to setup the tokens etc using javascript for more control of the user interface.

Feedback is welcome.

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

Goal:

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.

VOOT

Leif: Setup http://openvoot.org 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.

SAML2int

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: http://code.google.com/p/stinus/wiki/StinusOverview?show=content

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.

DiscoJuice

No updates.

Moonshot

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

OpenID Connect JWT and IDToken proof of concept implementations in javascript

To better understand JWTs and IDTokens I did a proof of concept implementation of JWT and IDtokens in Javascript. I did this 6 months ago, but just realized that I never referred to the work. I’m not sure how useful the work is, because it might be updated due to changes in the spec, and it is not feature complete.

However, if you’re inrested, here it is:

OpenID Connect Metadata

In order to build a dynamic registration service for OpenID Connect, a metadata format would be needed. While reading through the OpenID Connect specification, I wrote down the properties I though would be useful to know about an entity, in an example JSON metadata file. Here is my notes:

I also started thinking about dynamic registration and automated metadata distribution. Here are these notes: