Matthew Buckett wrote this article about the authentication technology that we opted to use to allow mobile phones to connect to WebLearn (Sakai).
“We went down the route of using OAuth between Mobile Oxford (m.ox) and Sakai as it allowed m.ox to make requests to Sakai on behalf of a user without the user having to give m.ox their password. (Oxford has a web single sign-on service (Webauth) which is the only place that users should enter the Oxford credentials).
An alternative would have been to trust authentication done by m.ox in any requests coming from them (for example,by having a signed header containing the username) but this means that any compromise on m.ox could expose all Sakai accounts.
By using OAuth only the users who have allowed m.ox access to their account are at risk from any compromise of m.ox. We are not saying m.ox is insecure, but as an application grows in size there are more points to attack.
OAuth is also a reasonably popular standard that existing tools/libraries support. This work builds on an existing Java OAuth implementation (Apache License)
http://code.google.com/p/oauth/
One probably needs to have a basic understanding of 3 legged OAuth to read bits of this article, see:
http://answers.oreilly.com/topic/1381-how-to-use-three-legged-oauth/
First off the code is in our public git repository and can be checked out with:
git clone git://git-repo.oucs.ox.ac.uk/git/repos/local-project/oauth
The web view of the repository is at:
http://git-repo.oucs.ox.ac.uk/cgi-bin/gitweb.cgi?p=repos/local-project/oauth;a=summary
Basically we wanted to allow m.ox to be able to make requests to Sakai with an OAuth token and allow Sakai to take the token, validate it and associate with the user who had issued the token.
To keep the code reasonably self contained we wrote a small servlet filter which looks for the OAuth token in any request and if it finds it attempts to validate it and authenticate the request based on it.
This can be seen:
This filter is bundled up into a jar so it can be added to the dependencies of an existing webapp. If the filter finds an OAuth token, as well as authenticating the request with it, it adds a SecurityAdvisor to the stack which only allows a whitelist of permission checks to succeed. This is to limit how much access someone can get with a OAuth token.
The tool in the OAuth project contains two parts, first is the set of webpages which are used to allow a user to authorise a consumer (m.ox). These are basically the standard ones shipped with the OAuth library which is used. The main difference is that I’ve hooked it up to Sakai’s store of tokens.
The second part of the tool is a Sakai tool which can be added to a user’s My Workspace which allows users to revoke tokens they have authorised. This allows users to remove m.ox’s access if they lose their phone. As a side note m.ox’s sessions last a lot longer than our standard Sakai ones. This was done because repeated username / password entry is a barrier to takeup and due to the limited permissions the exposure isn’t as great as a users normal login.
The OAuth tokens are stores in the Sakai database using Hibernate; this should be fine in a cluster.
The external OAuth library is put into /shared and this isn’t good as it infects all Sakai tools with it’s implementation, ideally this should be hidden behind a private API.
The list of consumers is also static so to add a new one a restart of Sakai is needed, this isn’t ideal but wasn’t too much of a problem for us as at the moment we only have one consumer.”
