This page discusses the implementation of an OpenID service.

Requirements

Firefox detects forms that offer OpenID and inject a "Sign in using your Firefox Identity" in it so the user can use it to sign in.

If it's a new site, Firefox adds it to the authorized sites for the user, by calling our Identity server. The request performs the authentication and returns an OpenID URL

The relying party can use this URL to authenticate the user

XXX Display authorized sites ?

XXX TBD - mconnor

Server Implementation

The server is a full OpenId 2.0 server that will authenticate the user against his Sync account.

The only difference with a regular OpenId server is that authorizing EPs is done automatically in case the Sync Password is provided on the checkid_setup call. In that case, the server verify the password and automatically add the site, then perform the usual redirect.

OpenID APIs

A user is identified by his e-mail.

GET or POST https://server/

 Performs an OpenId operation. Depending on the openid_mode 
 request parameter value, the server will perform a different process.
 
 * associate: creates an association with the EP.
 * authorize_site: adds an site to the list of authorized sites
 * check_authentication: checks that a given site is authorized
 * checkid_setup: check if a End User owns the Claimed Identifier.
 * checkid_immediate: XXX points to checkid_setup for now
 
 See below for more details.

GET https://server/user_email

 Discovery page for the user. Returns:
 
 * a Yadis page for clients that accept "application/xrds+xml"
 * an HTML page for other clients

authorize_site: adding an authorized site

XXX

check a site: checking an authorization

XXX

checkid_setup

XXX

Implementation details

The server prototype is here: http://bitbucket.org/tarek/server-openid

The server is implemented using server-core, for the authentication APIs
storage
- Users are stored in LDAP for Mozilla, but people can use alternative back-ends
- Site tokens are stored in MySQL, but people can use alternative back-ends
- the association handles are stored in memcached
The server uses the same node assignment library than Sync to associate a user to a server
A new multi-value field is added in the LDAP User object: service-enabled
- to enable OpenID for the user, an OpenID value is added
- The Sync value is used to enable/disable Sync.
- The account-enabled field is kept for a global de-activation of a user
Node assignment can be done on the first OpenID activation if Sync is disabled or not used yet.

The client prototype is here: http://hg.mozilla.org/labs/weave-identity/summary

See also, Account Manager specs: https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/3

Impact on Sync

If a user tries to create a new account in Firefox Sync via the wizard but already has OpenID activated
- we tell the user that there's an existing account and redirect him to the regular user authentication screen.
- we add Sync in service-enabled in LDAP on the first sync
If a user deletes his Sync account
- we remove Sync from service-enabled but don't remove the LDAP user
If a user tries to create a new account in the OpenID UI, and already has Sync activated, we warn that an account exists for that e-mail and propose to the user to activate OpenID through the user account management panel

Services/OpenId

Contents