Diff for "LEP/OpenIdRoadmap"

Not logged in - Log In / Register
Differences between revisions 3 and 7 (spanning 4 versions)
⇤ ← Revision 3 as of 2010-09-02 10:36:03 →
Size: 4516
Editor: stub
Comment:
← Revision 7 as of 2010-09-06 20:17:55 → ⇥
Size: 4933
Editor: gary
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

'''Bug Bug:210943 is the overarching bug about this.'''
Line 41: Line 43:
 1. Tear out OpenId Provider code. Implement simple Developer/Test OpenId Provider. Steps 1-5 are tech-debt, irrespective of whether we follow this plan.
Line 43: Line 45:
    The OpenId Provider we currently use for development and testsuite
    environments is needlessly complex, from when Launchpad was itself
    an OpenId Provider. We should tear out all of this code, implementing
    a minimal OpenId Provider.		  1. Sever ShipIt/Launchpad links. Bug:628832
Line 48: Line 47:
    The login screen can just be a single form containing:
        * a drop down list of the email addresses in the EmailAddress table.
        * a text box to use an email address not in the EmailAddress table.
        * a text box to override the OpenId Identity to use.
        * a login button.
        * a fail to login button.		  ShipIt is no longer being maintained by the Launchpad team but is still
 tied into the Launchpad data model. This makes it difficult to refactor
 parts of the Launchpad data model and ties ShipIt rollouts to Launchpad
 rollouts.
Line 55: Line 52:
    Doing this, we remove a load of code. It allows us to drop the
    AccountPassword and numerous legacy OpenId tables. It allows us to
    refactor the Account/EmailAddress/Person/OpenIdIdentifier parts of
    the data model.		  1. Tear out OpenId Provider code. Implement simple Developer/Test OpenId Provider. Bug:629167
Line 60: Line 54:
 1. Sever ShipIt/Launchpad links.  The OpenId Provider we currently use for development and testsuite
 environments is needlessly complex, from when Launchpad was itself
 an OpenId Provider. We should tear out all of this code, implementing
 a minimal OpenId Provider.
Line 62: Line 59:
    ShipIt is no longer being maintained by the Launchpad team but is still
    tied into the Launchpad data model. This makes it difficult to refactor
    parts of the Launchpad data model and ties ShipIt rollouts to Launchpad
    rollouts.		  The login screen can just be a single form containing:
  * a drop down list of the email addresses in the EmailAddress table.
  * a text box to use an email address not in the EmailAddress table.
  * a text box to override the OpenId Identity to use.
  * a login button.
  * a fail to login button.
Line 67: Line 66:
 1. Improve Launchpad/CanonicalSSO Integration.  Doing this, we remove a load of code. It allows us to drop the
 AccountPassword and numerous legacy OpenId tables. It allows us to
 refactor the Account/EmailAddress/Person/OpenIdIdentifier parts of
 the data model.
Line 69: Line 71:
    Currently, we mirror selected Launchpad information to the lp_* 'mirror' tables. These tables are then replicated using Slony-I to the CanonicalSSO databases.  1. Improve Launchpad/CanonicalSSO Integration. Bug:629169
Line 71: Line 73:
    At a minimum, the CanonicalSSO systems need to stop using the lp_Account table to map OpenId Identifiers to Launchpad Person data (such as TeamParticipation). The CanonicalSSO could use a mirror the Launchpad EmailAddress information to map CanonicalSSO accounts to Launchpad information, or some entirely different mechanism allowing us to seperate the CanonicalSSO and Launchpad databases into seperate replication clusters.  /* This is here to wrestle moin syntax into submission. Without it, the next para joins with the bullet point above. Non-hacky help welcome. */
Line 73: Line 75:
 1. Simplify the Account table.  Currently, we mirror selected Launchpad information to the
 lp_*
 'mirror' tables. These tables are then replicated using Slony-I to
 the CanonicalSSO databases.
Line 75: Line 80:
    Drop the displayname column on the Account table. Consider dropping the
    Account table entirely, linking OpenIdIdentifier directly to Person.		  At a minimum, the CanonicalSSO systems need to stop using the lp_Account
 table to map OpenId Identifiers to Launchpad Person data (such as
 TeamParticipation). The CanonicalSSO could use a mirror the Launchpad
 EmailAddress information to map CanonicalSSO accounts to Launchpad
 information, or some entirely different mechanism allowing us to seperate
 the CanonicalSSO and Launchpad databases into separate replication clusters.
Line 78: Line 87:
 1. Drop EmailAddress.account  1. Simplify the Account table. Bug:629170
Line 80: Line 89:
    Remove all Account and EmailAddress records not linked to a Person, reducing the number of Account records on the system by 90%. Drop the redundant EmailAddress.account link.  /* This is here to wrestle moin syntax into submission. Without it, the next para joins with the bullet point above. Non-hacky help welcome. */

 Drop the displayname column on the Account table. Consider dropping the
 Account table entirely, linking OpenIdIdentifier directly to Person.

 1. Drop EmailAddress.account Bug:629172

 Remove all Account and EmailAddress records not linked to a Person,
 reducing the number of Account records on the system by 90%. Drop
 the redundant EmailAddress.account link.
Line 84: Line 102:
    Currently, we are storing just the token used to generate the OpenId
    Identity URL. We should store the full URL.		  Currently, we are storing just the token used to generate the OpenId
 Identity URL. We should store the full URL.

OpenId Roadmap

Bug 210943 is the overarching bug about this.

Steps required to turn Launchpad into a normal OpenId Consumer.

As a user
I want to authenticate using my preferred OpenId provider
so that I have fewer credentials to manage

Rationale

A number of users would like to use their preferred OpenId provider rather than the Canonical OpenId provider (CanonicalSSO).

  • It is more convenient.

  • It is often more secure - if the OpenId provider is also the email service provider, only one party needs to be trusted.

  • It improves perception of Launchpad being a system for all Open Source developers, rather than for projects targetted at Ubuntu.

This work has not been scheduled. Launchpad is currently in a 'good enough' state, having offloaded authentication to the CanonicalSSO, and the authentication system contains a lot of tech debt that needs to be cleaned up.

Stakeholders

Our users.

ISD, maintainers of the CanonicalSSO and ShipIt.

Constraints and Requirements

Must

  • Keep ShipIt operational

  • Keep Launchpad Account creation easy for users happy to use the CanonicalSSO.

Nice to have

Must not

What MUST it not do?

Subfeatures

Steps 1-5 are tech-debt, irrespective of whether we follow this plan.

  1. Sever ShipIt/Launchpad links. 628832

    ShipIt is no longer being maintained by the Launchpad team but is still tied into the Launchpad data model. This makes it difficult to refactor parts of the Launchpad data model and ties ShipIt rollouts to Launchpad rollouts.

  2. Tear out OpenId Provider code. Implement simple Developer/Test OpenId Provider. 629167

    The OpenId Provider we currently use for development and testsuite environments is needlessly complex, from when Launchpad was itself an OpenId Provider. We should tear out all of this code, implementing a minimal OpenId Provider. The login screen can just be a single form containing:

    • a drop down list of the email addresses in the EmailAddress table.

    • a text box to use an email address not in the EmailAddress table.

    • a text box to override the OpenId Identity to use.

    • a login button.
    • a fail to login button.
    Doing this, we remove a load of code. It allows us to drop the

    AccountPassword and numerous legacy OpenId tables. It allows us to refactor the Account/EmailAddress/Person/OpenIdIdentifier parts of the data model.

  3. Improve Launchpad/CanonicalSSO Integration. 629169

    Currently, we mirror selected Launchpad information to the lp_* 'mirror' tables. These tables are then replicated using Slony-I to the CanonicalSSO databases. At a minimum, the CanonicalSSO systems need to stop using the lp_Account

    table to map OpenId Identifiers to Launchpad Person data (such as TeamParticipation). The CanonicalSSO could use a mirror the Launchpad EmailAddress information to map CanonicalSSO accounts to Launchpad information, or some entirely different mechanism allowing us to seperate the CanonicalSSO and Launchpad databases into separate replication clusters.

  4. Simplify the Account table. 629170

    Drop the displayname column on the Account table. Consider dropping the

    Account table entirely, linking OpenIdIdentifier directly to Person.

  5. Drop EmailAddress.account 629172

    Remove all Account and EmailAddress records not linked to a Person, reducing the number of Account records on the system by 90%. Drop the redundant EmailAddress.account link.

  6. Switch to using OpenId Identity URLs.

    Currently, we are storing just the token used to generate the OpenId Identity URL. We should store the full URL.

  7. Spec and implement workflow for signing up to Launchpad using a 3rd party OpenId Provider. Spec and implement workflow for attaching a 3rd party OpenId Identity to an existing Launchpad Account. Implement, rollout etc.

Workflows

What are the workflows for this feature? Even a short list can help you and others understand the scope of the change. Provide mockups for each workflow.

You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.

Success

How will we know when we are done?

How will we measure how well we have done?

Thoughts?

Put everything else here. Better out than in.

LEP/OpenIdRoadmap (last edited 2012-02-14 00:12:16 by wgrant)