launchpad development|
Size: 4933
Comment:
|
Size: 10725
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 123: | Line 123: |
| ''Put everything else here. Better out than in.'' | The following are notes about openid and identity from a conversation Curtis and Gary had recently. They are recorded as a brain dump in case they are useful later. Gary's writing this bit, so mistakes are his. We have several separate user interfaces to Launchpad: ssh + bzr; oauth + webservice; openid + browser; and email, with additional power provided by GPG signing. Each one of these has some method of providing Launchpad with a concept of trusted identity: ssh, openid/oauth, email, and GPG. Each should enable Launchpad to *uniquely* associate the input with a "Person" record. One notable thing about this for our discussion is that having access to an email account alone is sufficient for performing some actions on Launchpad. Alone, it is partially trusted. If you have GPG and email, you can do even more. To reiterate, email access is as good as openid for some activities. Openid relates to email because openid providers can include email addresses in their authentication messages. This can be a source a source of confusion. We see examples of this confusion with our trusted Canonical openid provider (see https://answers.launchpad.net/launchpad-foundations/+question/136307 and https://answers.launchpad.net/launchpad-foundations/+question/135971 for a couple of examples I can pull up in under a minute). Users don't understand that the systems are separate, or that setting a preferred email in Launchpad has little or nothing to do with the email they use to log into SSO. When they learn that they have to manage emails separately, they are understandably annoyed. Perhaps this confusion and annoyance will be less when the division between openid provider and Launchpad is greater because we will support many different openid providers. The openid-provided emails also give us some chances for automation. The automation can add to the confusion. We will first talk about the automation possibilities, and then discuss how they can add to confusion. An openid authentication to Launchpad can have one of the following three characteristics. * The openid provider includes email addresses in its authentication messages to Launchpad, and we trust the provider to give us verified email addresses. Canonical's SSO is an example of this kind of provider. We might also argue that we can trust Google's SSO, since it inherently includes a gmail account. We will call this TRUSTED. * The openid provider includes email addresses, but we do not trust them. This would be any openid provider that sends emails, and that we had not explicitly decided to trust (white list). We will call this UNTRUSTED. * The openid provider does not include email addresses. This would be any openid provider that does not send emails. We will call this NO EMAIL. The scenarios that we'll consider are these. * We have a TRUSTED or UNTRUSTED openid provider giving us an openid Launchpad has never seen before, with a validated email that is already associated in launchpad with an active (that is, not deactivated) person. We'll call this KNOWN EMAIL. * The same as the first one, but Launchpad has not validated the email. This is KNOWN UNVALIDATED EMAIL. * The same as the first one, but the person with the email is deactivated. This is KNOWN DEACTIVATED EMAIL. * We have a TRUSTED or UNTRUSTED openid provider giving us an openid Launchpad has never seen before with an email we've never seen before, or we have a NO EMAIL provider. This is NEW EVERYTHING. In the KNOWN EMAIL scenario with a TRUSTED openid provider, we have two trusted sources of emails. We can deduce that they are the same person, and simply connect the openid token with the existing person. Unfortunately this can increase the perception that the SSO and Launchpad are the same code base. Adding a step to confirm the connection, or at least a notification that it has happened, may help. If we are in the KNOWN EMAIL scenario with an UNTRUSTED provider, if the user wants to assert that they are the same person, I believe that we will need to do something like a merge of profiles: we will need to send out emails to some or all of the Launchpad emails to have them approve that the openid can be used for the account. Note generally in the KNOWN EMAIL scenario that, if the trusted, openid-provided email address is that of a team, we must not associate it (Bug:556680). With a KNOWN UNVALIDATED EMAIL, I don't quite know what to do and I don't think Curtis and I discussed it. With a KNOWN DEACTIVATED EMAIL, this is pretty much the same as what we should do if someone returns with a known openid for a deactivated account. Previously, the deactivation has made the emails unverified. We should verify with the user that they want to reactivate their account (we don't right now). If so, we can automatically verify emails from TRUSTED providers; for UNTRUSTED providers, as with NO EMAIL providers, we need to get email verification again before we can reactivate the account. With a NEW EVERYTHING scenario, Curtis has convinced me that we should ask users what to do before we create a new profile, and warn them that, if they expected to log in to an existing account, they need to use an older email address. We have gotten several confused users thinking that we had deleted their accounts because they logged in with a new or different email address. Other things to note: * Curtis tells me that a person can never delete all of their emails, even if they are deactivated. That's good. * The only way that a person can lose all of the emails is to be merged, or, right now, for the code in lib/lp/registry/model/person.py (getOrCreateByOpenIDIdentifier) to move an email. We strongly suspect that we should stop doing that last thing. |
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.
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.
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.
AccountPassword and numerous legacy OpenId tables. It allows us to refactor the Account/EmailAddress/Person/OpenIdIdentifier parts of the data model.
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.
Simplify the Account table. 629170
Drop the displayname column on the Account table. Consider dropping the
Account table entirely, linking OpenIdIdentifier directly to Person.
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.
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.
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?
The following are notes about openid and identity from a conversation Curtis and Gary had recently. They are recorded as a brain dump in case they are useful later. Gary's writing this bit, so mistakes are his.
We have several separate user interfaces to Launchpad: ssh + bzr; oauth + webservice; openid + browser; and email, with additional power provided by GPG signing. Each one of these has some method of providing Launchpad with a concept of trusted identity: ssh, openid/oauth, email, and GPG. Each should enable Launchpad to *uniquely* associate the input with a "Person" record.
One notable thing about this for our discussion is that having access to an email account alone is sufficient for performing some actions on Launchpad. Alone, it is partially trusted. If you have GPG and email, you can do even more. To reiterate, email access is as good as openid for some activities.
Openid relates to email because openid providers can include email addresses in their authentication messages. This can be a source a source of confusion.
We see examples of this confusion with our trusted Canonical openid provider (see https://answers.launchpad.net/launchpad-foundations/+question/136307 and https://answers.launchpad.net/launchpad-foundations/+question/135971 for a couple of examples I can pull up in under a minute). Users don't understand that the systems are separate, or that setting a preferred email in Launchpad has little or nothing to do with the email they use to log into SSO. When they learn that they have to manage emails separately, they are understandably annoyed. Perhaps this confusion and annoyance will be less when the division between openid provider and Launchpad is greater because we will support many different openid providers.
The openid-provided emails also give us some chances for automation. The automation can add to the confusion. We will first talk about the automation possibilities, and then discuss how they can add to confusion.
An openid authentication to Launchpad can have one of the following three characteristics.
- The openid provider includes email addresses in its authentication messages to Launchpad, and we trust the provider to give us verified email addresses. Canonical's SSO is an example of this kind of provider. We might also argue that we can trust Google's SSO, since it inherently includes a gmail account. We will call this TRUSTED.
- The openid provider includes email addresses, but we do not trust them. This would be any openid provider that sends emails, and that we had not explicitly decided to trust (white list). We will call this UNTRUSTED.
- The openid provider does not include email addresses. This would be any openid provider that does not send emails. We will call this NO EMAIL.
The scenarios that we'll consider are these.
- We have a TRUSTED or UNTRUSTED openid provider giving us an openid Launchpad has never seen before, with a validated email that is already associated in launchpad with an active (that is, not deactivated) person. We'll call this KNOWN EMAIL.
- The same as the first one, but Launchpad has not validated the email. This is KNOWN UNVALIDATED EMAIL.
- The same as the first one, but the person with the email is deactivated. This is KNOWN DEACTIVATED EMAIL.
- We have a TRUSTED or UNTRUSTED openid provider giving us an openid Launchpad has never seen before with an email we've never seen before, or we have a NO EMAIL provider. This is NEW EVERYTHING.
In the KNOWN EMAIL scenario with a TRUSTED openid provider, we have two trusted sources of emails. We can deduce that they are the same person, and simply connect the openid token with the existing person. Unfortunately this can increase the perception that the SSO and Launchpad are the same code base. Adding a step to confirm the connection, or at least a notification that it has happened, may help.
If we are in the KNOWN EMAIL scenario with an UNTRUSTED provider, if the user wants to assert that they are the same person, I believe that we will need to do something like a merge of profiles: we will need to send out emails to some or all of the Launchpad emails to have them approve that the openid can be used for the account.
Note generally in the KNOWN EMAIL scenario that, if the trusted, openid-provided email address is that of a team, we must not associate it (556680).
With a KNOWN UNVALIDATED EMAIL, I don't quite know what to do and I don't think Curtis and I discussed it.
With a KNOWN DEACTIVATED EMAIL, this is pretty much the same as what we should do if someone returns with a known openid for a deactivated account. Previously, the deactivation has made the emails unverified. We should verify with the user that they want to reactivate their account (we don't right now). If so, we can automatically verify emails from TRUSTED providers; for UNTRUSTED providers, as with NO EMAIL providers, we need to get email verification again before we can reactivate the account.
With a NEW EVERYTHING scenario, Curtis has convinced me that we should ask users what to do before we create a new profile, and warn them that, if they expected to log in to an existing account, they need to use an older email address. We have gotten several confused users thinking that we had deleted their accounts because they logged in with a new or different email address.
Other things to note:
- Curtis tells me that a person can never delete all of their emails, even if they are deactivated. That's good.
- The only way that a person can lose all of the emails is to be merged, or, right now, for the code in lib/lp/registry/model/person.py (getOrCreateByOpenIDIdentifier) to move an email. We strongly suspect that we should stop doing that last thing.
