[foaf-protocols] Ubuntu One and Authentication

Melvin Carvalho melvincarvalho at gmail.com
Sat Aug 21 09:28:34 CEST 2010


What I created in my GSoC project can be divided into 3 parts:

   1. Authentication
   2. Libraries
   3. User interfaces

1. Authentication

What originally started off as ubuntuone-auth, when I began the project is
now called ubuntu-sso-qt<http://bazaar.launchpad.net/%7Eapachelogger/ubuntu-sso-client/gsoc/files>.
The GNOME version (ubuntu-sso-client) just like the SyncDaemon exposes DBus
interfaces through which authentication is handled. The basic work flow at
this point is that a client requests authentication to an OAuth realm, SSO
will look for an appropriate token entry in the supported keyrings and yield
success if it found one, otherwise it will get an authentication process
going and then yields success (or failure, depending on the outcome [image:
;)] ). Suffice to say creating this was not terribly difficult to do but
nonetheless very interesting.

One of the key aspects of this application is that it starts an own web
server to make the OAuth experience better than what we are used to. I am
sure everyone hit a dialog asking you to press OK once you have
authenticated and authorized the application, upon which a browser opens
with some website to ask you to authenticate something (you can see that
sort of thing with the Facebook KIPI plugin for example). Instead of
dropping such a dialog *Ubuntu SSO will just launch a minimal HTTP server
and tell the SSO server (or rather the Ubuntu One one) to send the browser
back to that local server with OAuth token in the URL*. The local server
then extracts the OAuth information and redirects the browser the the proper
Ubuntu One web interface. At this point OAuthentication is basically done
and applications/libraries can use the token to access Ubuntu One.

In case you are interested, the HTTPDaemon is

The second nice thing about the Qt implementation is that it provides a
plugin interface for secret storage services. That way it is possible to use
any keyring/wallet as long as a plugin for it is available. Clearly this is
a very good thing because without a lot of programming effort it now
supports KWallet and GNOME Keyring while being itself implemented in Qt
only, so technically one could also use it on OS X and Windows and one would
just need to write additional plugins. It also helps with the fact that
(hopefully) soon a new implementation will become available as proposed at
which just another plugin is necessary.

And the best thing about my implementation is that, unlike the GNOME
version, it is not written in Python and hence not eating away your memory
right after startup for no good reason at all. In a KDE system it will use
about 0.1 MiB when idle and about 1 MiB when doing an authentication.
Finally, just to make my point of Python not necessarily being the better
choice: the undynamic C++ version supports KWallet *and* GNOME Keyring while
the Python version *only* does GNOME Keyring [image: :P]

More recently I became aware that the Ubuntu One team is working on
enhancing the client to actually provide GUIs and what not, to totally
eliminate the need for a browser window, which is probably a good idea. So,
that is something one could look into for the future. Also it should be made
central gateway to tokens, while right now each consumer will still lookup
the received tokens directly via the keyring/wallet it would make a lot more
sense to have Ubuntu SSO send the token in encrypted manner via DBus. I
certainly think that using the proposed secrets storage API for inspiration
on that would not be the worst of things.


Interesting post on how Ubuntu does single sign on with KDE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100821/65339926/attachment.htm 

More information about the foaf-protocols mailing list