<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../assets/xml/rss.xsl" media="all"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mardy (Posts about accounts)</title><link>http://mardy.it/</link><description></description><atom:link href="http://mardy.it/categories/accounts.xml" rel="self" type="application/rss+xml"></atom:link><language>en</language><copyright>Contents © 2026 &lt;a href="mailto:info@mardy.it"&gt;Alberto Mardegan&lt;/a&gt; </copyright><lastBuildDate>Sat, 11 Apr 2026 13:53:55 GMT</lastBuildDate><generator>Nikola (getnikola.com)</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><item><title>The Meego Accounts &amp; Single Sign On project</title><link>http://mardy.it/blog/2011/08/meego-accounts-single-sign-on-project.html</link><dc:creator>Alberto Mardegan</dc:creator><description>&lt;p&gt;One of the new features of the upcoming &lt;a href="http://swipe.nokia.com/"&gt;Nokia N9&lt;/a&gt; is the unified accounts UI  and the Single Sign On (SSO) framework. The developer website hosts a &lt;a href="http://www.developer.nokia.com/swipe/ux/pages/Accounts.html"&gt;page describing this feature&lt;/a&gt; in high level terms — a highly recommended reading — and offers a picture of the account creation flow (the orange circle representing the  finger tapping is a bit off target in the pictures, bummer):&lt;/p&gt;
&lt;div style="margin: 0 auto; width: 626px;"&gt;
&lt;img src="http://www.developer.nokia.com/swipe/ux/images/integrate_your_app/addaccount-thumb.png"&gt;
&lt;/div&gt;

&lt;p&gt;The  UX designers of the N9 decided to create a centralized place where all  the user’s accounts would be managed: all the account providers will be  listed in this application, and once the user chooses the provider and  enters his credentials (only once), he’ll be prompted to select which  services he intends to use on this account, in case the provider account  gives access to more than one. Once this is done, all the applications  interested in the selected services which have been enabled for the new  account will start using it.&lt;/p&gt;

&lt;p&gt;This design removes the need to implement account management in every  application, because all the accounts and their settings are handled in  the accounts UI application. Of course, applications can invoke the  accounts UI when an account needs to be created, and they can directly  embed the account configuration plugin when a specific account needs to  be edited.&lt;br&gt;
The accounts UI provides most of its functionality through &lt;b&gt;account plugins&lt;/b&gt;. There are &lt;em&gt;provider&lt;/em&gt; plugins, whose task is to create the account and handle those settings  that are shared through all the account’s services (such as a global  option to enable or disable the account), and &lt;em&gt;service&lt;/em&gt; plugins, which add support for a specific service within the account  and provide a configuration for its settings (at the very least, a  toggle switch to enable or disable the service). This plugin based way  of operate on accounts brings the possibility to extend the support for  new online services, with plugins possibly coming from different  sources, from the OS platform vendor to a user’s community, as well as  from a hardware vendor, third party software companies and application  stores. And all the new services can be directly accessible from the  same applications the user is already familiar with, instead of  requiring the installation of one additional stand-alone application.&lt;/p&gt;

&lt;p&gt;On the other hand, the &lt;b&gt;Single Sign On&lt;/b&gt; framework  is mostly transparent to the user (indeed, that’s the goal of any SSO  implementation): once the password for one service has been entered, all  applications operating on the same account should be able to login  without bothering the user with password dialogs. And if the password  turns out to be wrong, the SSO framework will ask for it &lt;em&gt;only once&lt;/em&gt;, no matter how many applications are using the account.&lt;br&gt;

Security  is also tightly bound to the MeeGo SSO implementation: at account  creation time it’s possible to specify which applications are allowed to  use a certain account (or, more technically, which resource tokens an  application must possess in order to be granted access to a certain  account’s credentials), and what authentication methods are allowed. For  instance, for security reasons we might not want to allow an account to  be used with any authentication method where the password is disclosed  in plain text to the applications or sent over the network.&lt;br&gt;
Last  but not least, the account passwords are stored on the device in  encrypted form, and the encrypted storage can be dynamically  activated/deactivated by providing/removing a master key, which could be  configured to be the user password, or a fingerprint or other biometric  checksum, some hardware key (such as a SIM card), or pretty much  anything else. When the encrypted password storage is unavailable and  some applications need to login to a service, the user will be prompted  for the needed service password (again not more than once per account);  all this being totally transparent to the application.&lt;/p&gt;

&lt;h4&gt;Using the framework in other devices/platforms&lt;/h4&gt;

&lt;p&gt;The  UI design for the Accounts &amp;amp; SSO components described above is just  one of the possible ways of integrating the MeeGo Accounts &amp;amp; SSO  framework into a user device. The framework itself has been written to  be flexible and support any UI workflow we could think of, without  compromises to performance or security. The deployment of the Accounts  &amp;amp; SSO framework in other devices and platforms has also been taken  into consideration during the architecture and implementation  development and several actions were taken towards this goal.&lt;/p&gt;

&lt;p&gt;The core software driving the Accounts &amp;amp; SSO frameworks is all open source (LGPL), and can be found in &lt;a href="https://gitorious.org/accounts-sso"&gt;gitorious.org&lt;/a&gt;. The most interesting components are:
&lt;/p&gt;&lt;ul&gt;
&lt;li&gt;&lt;a href="http://gitorious.org/accounts-sso/accounts-glib"&gt;libaccounts-glib&lt;/a&gt;: &lt;a href="http://en.wikipedia.org/wiki/GLib"&gt;Glib&lt;/a&gt;-based API for account management. Depends on &lt;a href="http://www.sqlite.org/"&gt;SQLite&lt;/a&gt; and &lt;a href="http://www.freedesktop.org/wiki/Software/dbus"&gt;D-Bus&lt;/a&gt;.&lt;/li&gt;
&lt;li&gt;&lt;a href="http://gitorious.org/accounts-sso/accounts-qt"&gt;libaccounts-qt&lt;/a&gt;: Qt API for account management. Thin wrapper of libaccounts-glib APIs.&lt;/li&gt;
&lt;li&gt;&lt;a href="http://gitorious.org/accounts-sso/signon"&gt;signon&lt;/a&gt;: the SSO daemon (written with Qt), which provides a D-Bus API. In the  same source tree there’s also the libsignon-qt library, for Qt-based  clients.&lt;/li&gt;
&lt;li href="http://gitorious.org/accounts-sso/signon-glib"&gt;libsignon-glib: Glib-based client API for SSO.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Most  of the other repositories in the project are probably not very useful  outside of MeeGo, and they are not that interesting anyway. What might  be more interesting to know, is the list of components that are missing  from the gitorious project (because they are not open source), and that  another platform/vendor would have to reimplement in order to provide  all the functionalities described above. Luckily, there’s not much in  this list. Apart from a couple of SSO authentication plugins for  specific services, the rest is all about UI parts (because of Nokia’s  general policy of not releasing the source code of its UI applications):  we &lt;i&gt;don’t&lt;/i&gt; have the account application and the account plugins, and the SSO UI  daemon serving the password dialogs. This is not a big loss because in  the UI would have had to be rewritten anyways to run in other platforms  (and for MeeGo as well, as the MeeGoTouch UI library which is used in  these Nokia UIs has been deprecated).&lt;/p&gt;

&lt;p&gt;Having  spent quite a considerable amount of (pleasant) time and energy on this  project, I feel rather bound to it even though my employment in Nokia  has ended. Therefore, I’m willing to continue to dedicate some of my  free time (which, I have to say, is not much) to contribute to it and  help its deployment in MeeGo and other Linux based platforms. Don’t  hesitate to &lt;a href="mailto:mardy@users.sourceforge.net"&gt;contact me&lt;/a&gt; if you are interested in getting the Accounts &amp;amp; SSO powering the OS you love and would like to know more about it.&lt;/p&gt;</description><category>accounts</category><category>english</category><category>kdeplanet</category><category>maemo</category><category>meego</category><category>Nokia</category><guid>http://mardy.it/blog/2011/08/meego-accounts-single-sign-on-project.html</guid><pubDate>Sun, 14 Aug 2011 17:20:00 GMT</pubDate></item></channel></rss>