launchpad-dev team mailing list archive

[William Grant <me@xxxxxxxxxxxxxxxxxx>]

Hi Curtis,

Thankyou for analysing these issues. They've been bugging me for a
while, and causing a terrible experience for a lot of users.

On Thu, 2010-09-23 at 18:28 -0400, Curtis Hovey wrote:
> The Launchpad user registration/login/reset has been broken for many
> months. As a subscriber to all launchpad bugs and questions, I can see
> there is a problem, but as a person who works with the Launchpad
> Registry team, I feel powerless to fix this. I think this sense of
> confusion is common for all the users and developers of Launchpad. Can
> the people with some knowledge take some time to elaborate and correct
> our common understanding of what is wrong and what can be done to fix
> it.
> 
> The crux of the problem is that Launchpad does not manage identity and
> credentials. Launchpad does not know who you (the person reading this)
> is, nor does it want to. Launchpad relies on Ubuntu's Single Sign On
> service to tell it which Launchpad profile you are at the moment.
> 
> I think login.launchpad.net is part of the problem. It misleads users to
> think Launchpad is managing user credentials. This site is really Ubuntu
> SSO.

I think that login.launchpad.net needs to disappear. It is simply too
confusing -- everyone has two independent sets of email addresses
associated with Launchpad.net.

It can't safely be destroyed now (forcing non-Ubuntu LP users to use an
Ubuntu-branded SSO site would be foolish), but it seems reasonable to do
it once LP becomes a general OpenID provider.

If it can, Launchpad also needs to link back to the provider. There's no
way to change one's password from the LP UI, and no hint as to where one
must go.

> What Happens When You Login
> ---------------------------
> 
> Here is a summary of the 3 parts that are in play when you login:
> Site:    Ubuntu-SSO  ->  Lp-internals   -> Lp-mainsite
> Team:    ISD-hackers     Lp-foundations    Lp-registry
> Domain:  user            authentication    person (profile)
> Analogy: driver          requisitioning    car
> 
> Users register with SSO. User can login to many sites. When you login to
> Lp, the site asks SSO who you are. Lp uses the identity information from
> SSO to select 1 of the 1 million modeled persons be your profile. Your
> profile's id and or your email address are used to select the profile
> you will become.

To clarify the insanity, the process works like this:

 - User goes to LP, clicks "Log In / Register"
 - LP redirects to SSO.
 - User logs into SSO
 - User confirms that SSO should send data to LP (why?)
 - SSO redirects back to LP, giving it the user's identity URL and
   primary email address.
 - LP looks up the Account related to the identity URL.
 - LP also looks up the Account related to the given email address.
 - LP compares the two Accounts. If the email address is on a different
   Account, LP reassociates the identity URL with that account.
 - The user is now logged in as a different Account and Person
   (bug #637968).

> Mismatched Identities
> ---------------------
> 
> This implies that SSO and Launchpad need the same email address
> information to consistently select the profile to match the credentials
> you provided, but that is not going to happen, *ever*.
> 
> While Launchpad discourages users from having multiple profiles, many
> chose to. Many users do not know they many profiles because Lp created
> them from imported email addresses. It can be a lot of work try to get
> Launchpad to know all your email addresses belong to one profile. You
> may also have many identities in Ubuntu SSO. The email addresses between
> the SSO identities and Launchpad profile can be mismatched. Try drawing
> the lines between the email addresses; it seems like a miracle when you
> login and actually get the profile you expect!
> 
> One human being
>  /           \
> SSO           Lp
> Identity_1    Profile_1
>   email_1       email_1
>   email_2       email_3
> 
> Identity_2    Profile_2
>   email_3       email_2
>   email_4
> 
>               Profile_3
>                 email_5 (in wrong state)
> 
> /me runs screaming from the room.

This issue goes away once LP becomes a normal OpenID consumer. It will
stop trusting SSO email addresses, and the SSO -> LP account map will be
based on an immutable SSO identity URL. That's bug #637968.

> User Issues
> -----------
> 
>       * People report they have not receive a confirmation emails for
>         registration or reset. This is usually a spam filter or grey
>         list issue that is outside the control of Lp or SSO. But, users
>         start asking for help from Lp staff in email and IRC. We forward
>         the users to https://forms.canonical.com/lp-login-support/
>         eventually. Why eventually? because many engineers are not aware
>         that Launchpad is using Ubuntu SSO. I have been asked twice in
>         the last 8 weeks to look up logintoken information that cannot
>         possibly exist in a Launchpad DB.
>
>       * People report they do not have Lp profiles (Lp ids). Launchpad
>         does not know their name or their email address--the user has
>         clearly never been to Launchpad. Some users were direct to
>         register at login.launchpad.net/+new_account which is not
>         Lp...the user never visited Lp and started login.

This confusion will probably disappear if login.launchpad.net does.

>       * People have asked me to delete their account information. I
>         cannot delete Lp profile information, but that is not the real
>         issue. The person is not registered with Launchpad, so there is
>         nothing that could be deleted
> 
>         ! Clearly state that registration/login/reset is SSO

This probably becomes easier once the OpenID identifiers are listed on
the Person page. You could even link from each to the provider's config
page.

>       * I am appalled when I see a user login with a profile with a
>         mangled Launchpad Id. "-deactivatedaccount" and "-merged" were
>         by deactivation/merging to free the profile namespace and
>         provide a visual indication that no one can be this profile. Yet
>         that is not so any more. I am also dismayed to read oops reports
>         involving users without email addresses (because the address is
>         in the wrong state). Launchpad has sane rules to ensure Ids were
>         fixed and emails restores when a profile was reactivated via
>         login/reset.
>         
>         ! The act of authentication must guarantee sane ids and
>         preferred email address.
> 
>       * User report their profile is wrong after they deleted an email
>         address in Lp. It have been suggest to never delete email
>         addresses, but hide them so that profile matching is not broken.
>         I do not want to do this *again*. I just fixed the bugs where
>         teams were not deleting email addresses. When I loose control of
>         an email addresses, I want it deleted. I do not want someone to
>         assume my identity. Maybe we can warn the user if the address
>         was used in authentication. Maybe we can add a rule to
>         disassociate the address from the profile and start a
>         confirmation process to restore it when the user first
>         authenticates with it.

This is the situation I described at length above (bug #637968). I think
the solution is to just stop trusting email addresses from SSO, avoiding
the "repair" process that breaks the accounts. We have OpenID; using
email addresses is silly.

>       * Users report their profile page is broken...we can see an broken
>         openid interaction in an oops. I have not idea what is broken or
>         how to fix it I believe some cases were fixed by direct SQL
>         manipulation of openid information and email addresses.

Bug #637968 again, yay. The crash occurs when a Person's Account has no
OpenID identifier associated. This profile is clearly impossible to log
in to, so it's not a normal situation. It occurs when the user has
deleted an email address, an automated process has recreated it in a
separate profile, and the "repair" code has reassigned the identifier to
that new profile.

>         ? Would this be a problem if Launchpad stopped being a proxy for
>         SSO? Could Lp removed the XRDS

You can't remove the XRDS. People use those identity URLs.

>  and RP supprt?

I don't think this is what you mean. RP == Relying Party, which is what
LP is moving *towards*. Do you mean that LP should stop being an OP
(OpenID Provider)? If so, I believe we already have: all that remains is
the XRDS on Person:+index, which must remain for compatibility.


In summary: fix bug #637968, make LP a general RP, destroy
login.launchpad.net.

William.

Attachment: signature.asc
Description: This is a digitally signed message part