Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


As users continue to move more and more of their data online they need ways to integrate those services with the applications that they use on their desktops. One part of this problem is account management as most providers have many different services, and thus will touch several applications on the desktop. The user should only have to enter account information once and be able to use that account throughout their desktop experience. This blueprint provides the storage interface for storing this data in a way that desktop applications can easily get to it.

Release Note

Ubuntu now supports the ability to configure network accounts in a centralized location and use those throughout the desktop.


Use Cases


The basics of the design are to have a separate datastore which can be queried by applications wishing to use network accounts. This "profile manager" will sit across DBus and provide a consistent interface to a variety of services that are available to any application. It will also provide a way for an application to get the appropriate login information required to use the service.



The basis of the architecture is a profile manager that sits as the central data store and configuration interface for the various applications and configuration utilities.


All of the applications will communicate with the profile manager using it's DBus API. No secure information will be sent over this connection, only configuration data. This includes things like which server to connect to, and how to connect to it, but not the password. Instead, instructions will be sent to the application for it to look in GNOME Keyring for the sensitive information.


Data Store

The data will be stored in GConf. This solution is used because it's already handled well by packaging systems that exist to provide a reasonable interface for updating and configuring profile data. Also, because of the nature of GConf's layered design users can update the information or change it to suit their desires easily. One would hope that this isn't a required feature, but we should provide this level of flexibility for users.

The data model will look like this:

The data was broken up into three categories. The lowest level category is services. The services are more program based, and will allow specific desktop applications to figure out what services they support easily. The second level is a profile, which relates more closely with the online identity provider and it's combination of services. Lastly there are account, which are specific instances of a profile. It is possible for a user to use a particular profile more than once.

It is important to note cases of where data is reused through out the data model. One example of that is the Jabber username. Here the Jabber username is configured to be the username specified in the profile then an "@" and the Jabber server. But, Jabber services like GTalk would want to reconfigure that, which is done in the profile instance of the service. Here the username could be overloaded to be a different value depending on what the profile required.



No previous data. Previous logins will not be migrated to the profile architecture.

Test/Demo Plan



DesktopTeam/Specs/NetworkAccountProfilesDatastore (last edited 2008-08-06 16:40:08 by localhost)