Ubuntu Wiki

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.

• Launchpad Entry: network-account-profiles-datastore

• Packages affected:

Summary

As users continue to move and more of their data online through various service providers they need ways to integrate those services with the applications that exist on their desktop. One part of this problem is in account management as most services encompass many different features, 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.

Rationale

• The importance of network services has increased over the last few years. Call it Web 2.0 or any other buzzword that you'd like, but users now expect these services. It's important that we start building ways for these services to get into desktop applications.
• Canonical is planning to be a provider of network services to Ubuntu users that enhance the Ubuntu experience. Many services that require connecting between multiple computers and devices require an intermediary network server, but it must be easy to use. This framework will lay the basis for providing such services on Ubuntu.

Use Cases

• A user logs into their IM client with an account that provides other services. When using those other services in other desktop applications should not have to prompt for login information and should be able to use the information already supplied by the user.
• An application provides a network related service and would like to check if there are any shared login accounts that could be used. It can query to see which accounts are known and which are services are available without having to maintain that information itself.

Design

The basics of the design are to have a separate logical entity (may be a processes, but more likely activated by DBus) 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.

Requirements

• All applications should be able to query the profile manager independent of programming language and/or UI toolkit.
• The profile manager should support being updated by users as well as the system.
• Applications should be able to query based on service or protocol
• The profile manager should use secure locations for passwords or other sensitive information

Architecture

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.

attachment:unet_users.png

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.

attachment:unet_gnome_keyring.png

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:

• /apps/profile-manager
  • profiles
    • Ubuntu.net
      • name: "Ubuntu.net"
      • description: "A set of network services enhacing the Ubuntu experience"
        • data

          • username: "default@ubuntu.net"

          • password: "gnome-keyring"
        • services
          • mail
            • profile: "imap"
            • username: "{username}@u.net"
            • server: "imap.ubuntu.net"
            • ssl: true
          • im
            • profile: "jabber"
            • server: "jabber.ubuntu.net"
  • services
    • imap
      • username: "{username}"
      • password: "{password}"
      • server: "imap"
      • ssl: false
      • auth: "password"
    • jabber
      • username: "{username}@{server}"
      • password: "{password}"
      • server: "localhost"
      • ssl: false
      • port: 5222
  • accounts
    • account1
      • profile: "Ubuntu.net"
      • username: "ted-gould"
      • password: "profile-manager-3BD43"
    • account2
      • profile: "Ubuntu.net"
      • username: "mark-shuttleworth"
      • password: "profile-manager-43AB8"

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.

Implementation

• Build a GConf structure for containing all the basic profile data. This will allow packages to easily update the information, as well as, allowing users to change it.
• Build a small DBus service that will provide a simple API for applications but then will connect to the GConf data backend.
• Define a DBus API

Migration

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

Test/Demo Plan

Comments

CategorySpec