NetworkAccountProfilesLaunchpad

Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2008-06-09 21:31:57 →
Size: 2705
Editor: 65
Comment:
← Revision 2 as of 2008-06-10 06:09:39 → ⇥
Size: 2690
Editor: pool-71-106-27-36
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
Launchpad authentication is an important network profile to support. Because we can control both ends of this authentication mechanism we can make it more secure and robust than other network acount profiles. This means we should make it more secure and robust. One of the profiles that we are planning to support is the "Ubuntu.net" profile which will use the Launchpad authentication infrastructure for account authentication. Because we are able to control both the backend and frontend of this implementation, the overall solution can be more robust than other interfaces allow.

The main advantage that the Ubuntu.net solution will provide is by not using the username/password as the desktop token, but instead to use an actual generated token by the Launchpad authentication architecture. This token can then be used by applications on the desktop in order to authenticate with the various Ubuntu.net services. There will be no reason to store the username and password on the desktop. Also, these tokens may be expired by the Launchpad Authentication Architecture, so the cases where we have an expired token will have to be handled explicitly.
Line 16: Line 18:
 * 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.		  * Canonical is planning to be a provider of network services to Ubuntu users that enhance the Ubuntu experience. Launchpad authentication is the basis for those services.
Line 25: Line 26:
The Launchpad authentication mechanism is to a slightly modified OAuth authentication. It's slightly modified in that it won't require a webbrowser to submit the username and password, it will be entirely done using a network API.
Line 26: Line 28:
=== Requirements === The entire transaction will result in the generation of a token that validates this computer as being authenticated to Launchpad. Initially all services will use the same token. No account information will need to be shared with the service, only the toke and it assumed that the backend will appropriately deal with token. These tokens will be a string of currently unspecified length. They are considered secure assets and should be stored in the keyring.

== Requirements ==
Line 31: Line 35:
=== Architecture ===
Line 36: Line 37:
One of the profiles that we are planning to support is the "Ubuntu.net" profile which will use the Launchpad authentication infrastructure for account authentication. Because we are able to control both the backend and frontend of this implementation, the overall solution can be more robust than other interfaces allow.

The main advantage that the Ubuntu.net solution will provide is by not using the username/password as the desktop token, but instead to use an actual generated token by the Launchpad authentication architecture. This token can then be used by applications on the desktop in order to authenticate with the various Ubuntu.net services. There will be no reason to store the username and password on the desktop. Also, these tokens may be expired by the Launchpad Authentication Architecture, so the cases where we have an expired token will have to be handled explicitly.		  * TODO

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.

Summary

One of the profiles that we are planning to support is the "Ubuntu.net" profile which will use the Launchpad authentication infrastructure for account authentication. Because we are able to control both the backend and frontend of this implementation, the overall solution can be more robust than other interfaces allow.

The main advantage that the Ubuntu.net solution will provide is by not using the username/password as the desktop token, but instead to use an actual generated token by the Launchpad authentication architecture. This token can then be used by applications on the desktop in order to authenticate with the various Ubuntu.net services. There will be no reason to store the username and password on the desktop. Also, these tokens may be expired by the Launchpad Authentication Architecture, so the cases where we have an expired token will have to be handled explicitly.

Release Note

Ubuntu users can log into Launchpad services including those provided by Canonical using network account profiles.

Rationale

  • Canonical is planning to be a provider of network services to Ubuntu users that enhance the Ubuntu experience. Launchpad authentication is the basis for those services.

Use Cases

  • User should be able to use Launchpad authenticated services with NAP enabled applications

Design

The Launchpad authentication mechanism is to a slightly modified OAuth authentication. It's slightly modified in that it won't require a webbrowser to submit the username and password, it will be entirely done using a network API.

The entire transaction will result in the generation of a token that validates this computer as being authenticated to Launchpad. Initially all services will use the same token. No account information will need to be shared with the service, only the toke and it assumed that the backend will appropriately deal with token. These tokens will be a string of currently unspecified length. They are considered secure assets and should be stored in the keyring.

Requirements

  • Authentication should be able to be revoked from Launchpad itself
  • No user login or password should be stored on the local machine in any form

Implementation

  • TODO

Migration

No previous data.

Test/Demo Plan

Comments

CategorySpec

DesktopTeam/Specs/NetworkAccountProfilesLaunchpad (last edited 2008-08-06 16:31:49 by localhost)