User created a second Launchpad account; now gets mixed success/denied to various services

At the moment, the Canonical SSO (login.launchpad.net/login.ubuntu.com) links a Launchpad account to a single OpenId identifier. This is reset when you log into Launchpad. So if you log into Launchpad using your first login.ubuntu.com account, and then log into a different service with your second login.ubuntu.com account, your Launchpad credentials are not reported. Also, this information is replicated asynchronously from Launchpad to the Canonical SSO so there is lag that can cause confusion.

Solution should be to use one Canonical SSO account and stick with it.

So, I was trying to create a LP account that is not in ~canonical, for testing.

Some voodoo magic happened, and even though I was logged out, it associated this new account with my existing ~canonical account.

I can keep a different firefox profile for this in the future, but as of now the question is: how do we untangle the mess?

I am supporting a user who has also been hit by this.

She now has two login.u.c accounts associated with her single LP account; the email addresses for her login.u.c accounts match the primary and secondary email addresses in her LP account.

The interesting bit is her two login.u.c accounts have two totally different passwords. She can successfully login to her LP account using either login.u.c email address and its respective different password.

On Thu, Sep 23, 2010 at 4:35 AM, Sean Sosik-Hamor
<email address hidden> wrote:

> I am supporting a user who has also been hit by this.
>
> She now has two login.u.c accounts associated with her single LP
> account; the email addresses for her login.u.c accounts match the
> primary and secondary email addresses in her LP account.
>
> The interesting bit is her two login.u.c accounts have two totally
> different passwords. She can successfully login to her LP account using
> either login.u.c email address and its respective different password.

I'm not sure what the problem is here. This is working as expected.

--
Stuart Bishop <email address hidden>
http://www.stuartbishop.net/

The problem is, that both people affected by this (myself and Ali, who Sean is helping) cannot login to directory.c.c. I also can' t access status.c.c. They respond as if I'm not in ~canonical with the error "not granted access to this resource."

Steve tried to delete my 2nd openid identifier in LP, but got some error (I'll let him follow up).
We need help un-doing the mess. I don't want the new ID associated with my LP account.

The root bug here is that SSO only associates a single login with a particular launchpad account, as Stuart describes. Solving that (or supporting merging accounts somehow) would make this go away. I'll add SSO to this bug for ISD to confirm or deny.

That might not happen quickly, and people need to use their accounts.

We're happy to help with trying to delete accounts, and finding a workaround. After that, we'll downgrade this to High and pass it off to ISD.

That said, deleting LP accounts should not be (is not supposed to be) necessary to make this work. What Stuart said--logging in as a single openid account, then using that to log in to Launchpad, and then logging in other places--should be sufficient. If it is not, we have problems.

In that vein, I talked with Charlie on IRC. I requested that he log into LP with one account, and then go to directory.c.c and see if it works. He reported that, with a new FF profile, he logged into LP just fine. Then he want to directory.c.c, which redirected him to login.u.c, which looped back and forth with directory.c.c, and then finally gave him an internal server error on login.u.c.

I'm going to try and find someone on ISD now to look into this, because even the short term solution may be entirely out of Launchpad's hands.

SSO indeed only associates a single OpenID to each account. This is not something we were planning on changing even in the long term. At the moment we consider the openid_identifier for each account immutable, and it's often used as a dependable identifier for an account, while displaynames and nicks can change.

We do have plans for allowing accounts to be merged, but the resulting account will only retain one OpenID.

Discussing with gary, currently what is replicated over in the lp_account table is the last openid that the LP user signed in with. In this case either one or the other SSO account should always have the LP information (namely username and team membership) associated.

So, if we're not missing anything, signing out of https://login.ubuntu.com/ and then logging in on status.c.c should allow you to try with each account in turn and eventually find the one that's mapped to your LP team memberships.

Exactly which SSO account has access will change with the information SSO receives from LP. This is an ugly situation that could be avoided by providing a row for each openid in the lp_account, allowing for duplicates in the id column. We'd need to add an extra column to act as a primary key for that table.

If that's done, *all* SSO accounts will have access to the LP information, which is a much more consistent place to be in. Nevertheless, if somebody still wants a separate account without ~canonical privileges they'd have to avoid LP from merging the two LP accounts.

I spent much of the day trying to diagnose this problem with Charlie and Anthony. In the previous comment, Anthony describes what we agreed should be the long term solution, barring objections from Stuart; and what we all thought ought to work as the short term solution.

To be clear, this appears to have been a failure of the LP Foundations team/myself in identifying our change (which allows multiple openids to be associated with a single LP account, thereby fixing several bugs) as a potential problem that needed to be presented to ISD and tested. We believed it would be transparent, and it was not. We will learn from this.

Charlie was very accommodating in trying different variations of our short term solutions. He did each one with a new browser profile, so browser cookies, such as on directory.c.c, should not have been an issue. He tried logging out of Launchpad and SSO. None of it worked. We still do not have a workaround. This needs to be worked on until we have a workaround--he and Ali have access.

The original bug description says that the user created a second LP account. AFAICT, while checking with Charlie confirmed that this was his perception, from a technical perspective, this really means that he clicked on Login/Register, *which took him to the SSO application*. Therefore, I'm pretty sure that's what happened.

I tried duplicating the problem with a new email address on my own account. I was unable to, and various hypotheses I had were dead ends.

I'll pass this on to stub for more work on a workaround. His familiarity with the DB will hopefully resolve this in short order.

Clarification: This needs to be worked on until we have a workaround--until he and Ali have access. They still do not have consistent access.

One quick clarification @Anthony - an OpenId Identifier is linked to a single SSO Account (In LP we consider them pretty much the same thing). A Launchpad Account can be associated with multiple OpenId Identifiers. Currently the SSO system only knows about a single LP Account -> OpenId link, which is Bug #644975.

I have a feeling confusion is being caused when people are logged into login.ubuntu.com and login.launchpad.net with different accounts. It would be worth trying:

 - Go to login.ubuntu.com and logout
 - Go to login.launchpad.net and logout
 - Log into Launchpad with your @canonical.com account
 - Log into the directory with your @canonical.com account

On Thu, 2010-09-23 at 14:00 +0000, Charlie Schluting wrote:
> Steve tried to delete my 2nd openid identifier in LP, but got some
> error (I'll let him follow up).

I tried to delete the spurious account via login.u.c administration
pages. ie, via the delete button.
The application crashed hard with an apache 5xx error. Not even an oops,
or python stack.

If the above process doesn't clarify what is going on, we can trash the OpenID -> LPAccount mappings in the Launchpad database. :

DELETE FROM OpenIdIdentifier USING Person WHERE OpenIdIdentifier.account = Person.account AND Person.name='cschluti';

Next time people log on, the OpenIdIdentifier will be mapped to the LPAccount with a matching email address.

On 09/24/2010 08:14 PM, Stuart Bishop wrote:
> I have a feeling confusion is being caused when people are logged into
> login.ubuntu.com and login.launchpad.net with different accounts. It
> would be worth trying:
>
> - Go to login.ubuntu.com and logout
> - Go to login.launchpad.net and logout
> - Log into Launchpad with your @canonical.com account
> - Log into the directory with your @canonical.com account

Hi,

This was suggested multiple times, so I want to clarify. In testing,
I've *always* been creating a new firefox profile, every time. I have no
cookies or sessions established.

If I first login to launchpad with my @canonical.com account, I get the
following results from two spot checks:

1) directory: redirects to login.u.c, I login with @canonical, and then
it commences a redirect loop back and forth.
2) status.canonical.com: it tells me I don't have access (like I'm not
in ~canonical).

 -Charlie

Ok.

I've removed Charlies OpenId Identity -> LPAccount mappings in the Launchpad database to clear the Launchpad end of things. I'm still unsure as to the underlying bug though given Charlie's report.

It all works now, thanks much! (in my existing browser session, I did
have to explicitly log out of both LP and SSO to successfully auth to
directory.c.c)

 -Charlie

I'm pulling this back down to high, since Charlie now can log in, and we haven't heard further from Sean/Ali. Sean, has that also been resolved, or do we need to do something there?

Thank you, Stuart.

Fixed in db-stable r9864 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/9864>.

Bad bot, no cookie.

the qatagger doesn't believe in no-cookie, so we're going to be editing the status here to get past deployment, will restore it later.

We've just had another report seemingly related to this bug:
RT#42155

* launchpad ~jjchen421
* 2 email addresses, a gmail one, and an @c.c one
* openid "A"

* on the openid side, we can access her @c.c address/account which has openid "B"
* haven't yet been able to find her gmail account - if it exists there

This is basically causing all sorts of havoc for her in terms of being able to login or not.

So in this case, it appears we have a single LP account, that manages to associate, at least partially with one openid account; and partially with another.

Ok, I've been able to find the other account in SSO that's associated with the gmail address (per Steve's comment above) and it does indeed have the OpenID identifier of the account in LP, which explains why it always thinks this user is connected with that email.

I have contacted ISD with the information about the new table we export. They hope to integrate it very soon. This should be the long term fix for the problem.

For jjchen421, we will need to do a band-aid. I'll try to work out the incantation that stub did for Charlie on comment #14, and then we can apply it to jjchen421, and ask her to log into Launchpad with the Canonical address, and then log into the other Canonical sites (directory and so on). She should avoid using the gmail account for authenticating with SSO until ISD has integrated the new table.

We will have to do this sort of thing until the table is integrated.

We mirror the table, but apparently we do not yet replicate it. I'll ask stub to look into it ASAP.

The RT for jjchen421 is resolved (thank you mthaddon and spm). I'm once again pushing this back down to High, but I will ask Stuart B to address the replication as soon as he is available, and then ISD has said they will make it a priority to integrate the new table. The bug will be resolved then.

The lp_OpenIdIdentifier table is now replicated to the SSO databases. The SSO should use this table instead of lp_Account to map an openididentifier to a person.

To retrieve all the teams participated in by openid identifier 'foo':

select team.name
from
    lp_openididentifier,
    lp_person as person,
    lp_teamparticipation,
    lp_person as team
where
    lp_openididentifier.identifier = 'foo'
    and lp_openididentifier.account=person.account
    and lp_teamparticipation.person = person.id
    and lp_teamparticipation.team = team.id;

The SSO staging database will need to be rebuilt using tomorrows backup.

@stub: Can you confirm the new table is available in both production and staging sso dbs now, and ready to use?

The tables are live on production.

I don't know about the sso staging database (or what server it runs on now).

The new table is now on sso staging and we can get started on the fix for this.

Just had another account need fixing. Applied the delete per comment 12.
 ~lli5, fwiw.

FWIW, I ran into this one too... details are here:

https://answers.launchpad.net/canonical-identity-provider/+question/150135

It was resolved by deleting one of the openIDs.

Hi,

just wanted to know if this issue has already been resolved, so that we can close up this bug.

Thanks,
Ricardo