Foundations/LPAsOpenIDRP

Not logged in - Log In / Register

Launchpad as an OpenID RP

Here are some notes on how we're going to change Launchpad to use login.launchpad.net (through OpenID) to authenticate users.

Later we might change Launchpad to use whatever OpenID provider is specified by the user, but that's out of scope here.

Migration plan

There's a chance that the rollout happens after a user started the registration process but before it's finished.

If that happens, once the roll out is finished the user will follow the link and try to complete the registration. At that time we need to either allow them to create a fully-functional account (i.e. one that works on login.launchpad.net as well) or tell them to start over on login.launchpad.net.

If during the rollout we split the auth/main databases for real, we won't be able to create a fully-functional account (as we won't have access to the auth DB, used by login.lp.net), so we'll need to change the logintoken view to direct users to login.lp.net.

However, if we do the real auth/main split on a subsequent rollout, we'd be able to create a fully-functional account with the existing code, not disrupting the user's experience.

The same would happen with someone trying to reset their password.

Cleanup unused (reset-password and new-account) login tokens between the two roll outs to avoid the problems above.

Notes on the main/auth split

The plan is to do the split but copy the EmailAddress and Account* tables over to the main db, later refactoring Launchpad to not use the Account* tables.

When Launchpad gets a positive assertion for an identity URL it hasn't seen before, it will just create a new Person/Account using the given email address, name (if any) and identity URL.

What to do about claiming of existing Person entries? We won't be able to do that in Launchpad because we'd need to set a password for the new account.

Before the refactoring

After the refactoring

Things to consider before doing the split

Any code in Launchpad that changes the AccountPassword table is likely to represent a user being fooled into thinking their password was changed when in fact it was not -- remember the AccountPassword table copied to the main DB is not the one used when people login using login.lp.net. For that reason, we should do something about the following:

Person.password should be removed

Notes from stub

I think the process will be:

At this point, the Ubuntu SSO appservers will be connected to their new database and totally disconnected from Launchpad except for the lp_person, lp_teamparticipation and lp_personlocation tables which we will continue to replicate. The launchpad_prod_4 database on sweetcherry is only being accessed by Launchpad. We can perform a similar procedure as above to stop using it entirely, or wait until the next Launchpad rollout. Then the hardware can be returned (Ubuntu One hot spare I believe?)

Also at this point, the Launchpad staging database becomes useless to ISD. On the up side, maintaining your own staging database will be pretty trivial and fast to refresh (just a pg_restore of the Ubuntu SSO production database should do the trick, with a little magic to strip the Slony-I crud).

I'm not sure of the best time for this to occur. I suspect it is after login.launchpad.net has been disabled and replaced by login.ubuntu.com. This way we don't have to worry about inconsistencies between the Launchpad copies of the authdb tables and the Ubuntu SSO copies of the authdb tables. If this doesn't matter, we can do the switch any time.

We can spare some Launchpad hardware for a fail over database if you don't have a server available, using Slony-I for replication. If you want to use something different (such as pgpool-II for synchronous replication & automatic fail over) we can incorporate that into the above process but that should be on your own hardware. Or you can make any changes later at your leisure. I'll still need to be involved in database updates while you are using Slony-I due to the way we are replicating the lp_* tables.

[1] The Django tables created for the new Ubuntu SSO service ISD is writing. [2] The Launchpad account tables - Account, AccountPassword, OpenID*, EmailAddress [3] lp_person, lp_teamparticipation & lp_personlocation, replicated from the Launchpad database. These tables are mirrors of the Person, TeamParticipation & PersonLocation tables in the launchpad database.

Salgado's reply

Given that users might start a registration/password-reset in launchpad.net before it becomes an OpenID RP, finishing the process after it becomes an RP, we should give them at least a few days after the rollout to finish the process using the existing tokens (through launchpad.net). We must also consume/delete the non-consumed LP tokens for registration/password-reset before doing the split.

Foundations/LPAsOpenIDRP (last edited 2010-02-26 14:28:49 by gary)