Online Accounts

Documentation for Application Developers
Documentation for Service Developers

For more information, or to follow the discussion, please subscribe to the ubuntu-online-accounts Mailing List.

Terms and definitions

Online Accounts uses some straightforward terminology, that is nevertheless important to outline before further discussion.

• account: an account is given by a provider to a user, and allows access to services.
• provider: a provider gives out accounts to users, as well as allowing them to use the account with a variety of services. A user can have multiple accounts by the same provider, and each account can have multiple services.
• service: a service is hosted by a provider, and allows the user to perform some task.
• service type: a service type describes what is the main functionality provided by a service. Service types are a useful way to group services which support a certain functionality. Examples are “calendar”, “e-mail”, “sharing”.

Architectural overview

Components of the Online Accounts framework

Here follows a listing of the components of the Online Accounts framework represented in the architectural diagram above.

Online Accounts applet in system settings

This is the application which allows users to create, edit, re-authenticate and delete their online accounts.
It uses libaccounts to enumerate the existing accounts, and loads a provider-specific account plugin when the user needs to create, edit, re-authenticate or delete an account. Such operations are delegated to plugins because the account configuration logic can vary considerably depending on the account.
Debian package name: gnome-control-center-signon
Project homepage: https://launchpad.net/gnome-control-center-signon

Provider-specific account plugin

These are the modules loaded by the Online Accounts applet in order to create, edit, re-authenticate or delete an account. In order to add support for a new provider, a new account plugin will have to be created (read more about this in the Online Accounts for service developers section). Typically, the account plugin would store the account settings into libaccounts, and the user credentials into signond (which can also help with the account authentication).
Debian package name: account-plugin-<provider>
Project homepage: some account plugins can be found at https://launchpad.net/account-plugins

libaccounts

This library provides the API to interface with the database of the configured accounts. Applications using Online Accounts typically start by enumerating the accounts which are relevant to them, retrieving the settings for those accounts and, when needed, bringing them online by using signond’s APIs. Note that there is no dependency between libaccounts and signond, other than the fact that the handle to the signond account credentials is stored as a setting in libaccounts.
Debian package name: libaccounts-glib-dev, libaccounts-qt-dev
Project homepage: http://code.google.com/p/accounts-sso

Signond

The signon daemon is a D-Bus service which handles the authentication process on behalf of the client application. The signond implementation allows using different backends for storing the user’s credentials and for handling requests which involve UI interactions (in the Ubuntu desktop these roles are filled by the GNOME keyring storage backend and the signon-ui service). In order to perform the authentication, signond loads an authentication plugin which will receive the user credentials in input (plus a few other parameters) and returns a response which signond will forward to the client.
Debian package name: signond (daemon), libsignon-glib-dev, libsignon-qt-dev (client libraries)
Project homepage: http://code.google.com/p/accounts-sso

Authentication plugins

These modules are loaded by the signon daemon in order to perform the authentication step; each authentication plugin handles one authentication method. The plugin receives the user credentials and some other method-specific parameters as input and provides a dictionary of data as response. This can be as simple as the password itself, or it can be an OAuth-like authentication token, or a SASL response. If needed, the authentication plugin can access the network and/or ask signond for additional information which might involve UI interactions, such as opening a web URL or solving a CAPTCHA challenge.
Debian package name: signon-plugin-<method>
Project homepage: some plugins can be found at http://code.google.com/p/accounts-sso and https://launchpad.net/signon-plugin-google

Signon-ui

This is the component which handles all UI interactions which might happen during the authentication. It is a D-Bus service whose APIs are meant to be used by the signon daemon only, usually upon a request by the client application or by an authentication plugin. The signon-ui implementation in the Ubuntu desktop can display dialogs for entering passwords, solving image-based CAPTCHA challenges (though it’s not hard to extend it to handle more complex CAPTCHAs) or showing web pages into an embedded browser widget (WebKit-based). These dialogs can be set as modal to a window, embedded using the XEmbed protocol or completely prevented from appearing, depending on the needs of the client application.
Debian package name: signon-ui
Project homepage: https://launchpad.net/signon-ui

GNOME keyring

The GNOME keyring is a standard component of the GNOME desktop. It offers an API to store and retrieve passwords and other secrets, and stores them securely on disk. Ubuntu Online Accounts comes with a storage plugin for the signon daemon which makes it store the password and authentication tokens (and generally, all data which the authentication plugin needs to store) into the GNOME keyring.
Debian package name: signon-keyring-extension
Project homepage: https://launchpad.net/signon-keyring-extension