Comment 15 for bug 881019

On 20/01/12 14:15, Monty Taylor wrote:
> On 01/20/2012 09:22 AM, William Grant wrote:
>> On 20/01/12 00:52, Monty Taylor wrote:
>>> It is on our todo list to use the team information from the OpenID
>>> response directly in gerrit. Once we do that, I can stop having to do
>>> the batch create of user accoutns in gerrit. However, that means a Java
>>> patch to Gerrit core, so it's probably not going to get done tomorrow. :)
>>>
>>> In terms of API additions, team info for a given OpenID identifier would
>>> not be useful - what I need is to get via the API is the OpenID
>>> identifier for a given user. If I could get that, I could stop
>>> screen-scraping.
>>
>> A user doesn't have a unique OpenID identifier. They can have multiple
>> due to account merges, and eventually several from different providers.
>> We could possibly allow them to select the primary identity, but really
>> you should be looking things at authentication-time, not before.
>
> I can't just look at things at authentication-time, because gerrit has
> multiple different access mechanisms. One of those is through the web,
> another is ssh. Also, gerrit doesn't support Launchpad's group extension
> yet, so the import is the best I've got.

But presumably the OpenID identifier isn't relevant to SSH :)

> That having been said, it may be the case that a user has more than one
> identity in the current system as a happenstance, but is that really the
> design? You're telling me that it's on purpose that there is no way to
> map the Launchpad User ID "mordred" to the openid identifier that will
> be returned if I try to log in via OpenID to that account? I'd love to
> hear why that's an intended design and not either a bug or a
> happenstance of how account merges got implemented. Up until this point,
> everyone else I've spoken to seems to think that the discrepancy is a bug.

OpenID identifiers are very similar to email addresses. A user may have
several that they use in different places (in no small part because of
the proliferation of awkward providers-but-not-true-consumers like
Launchpad), and Launchpad needs to be able to identify the user by all
of them.

Now, Launchpad is still restricted to a single provider. This means that
multiple identifiers don't occur except when people mistakenly create
multiple SSO accounts, log into Launchpad with both, and merge the two
resulting Launchpad profiles. And it's not clear which identifier should
win when merging profiles, so we keep both linked, letting both SSO
accounts log into the one profile.

SSO can't really sensibly do account merging. That would cause one of
the identifiers to disappear, locking the user out of any accounts on
consuming services that only know about the duplicate identifier. In a
lot of cases the user probably hasn't used the second SSO account for
anything notable, and really wants to entirely destroy all trace of
duplicate account from both SSO and Launchpad.

But there's presently no way for users to manage their identifiers. If
there was, we could allow them to remove the unwanted duplicates, and
select their primary identity -- just as we do with email addresses.
This hasn't been done largely because at this stage LP accepts only a
single provider, so the cases where this is necessary are extremely rare
(in fact, all but ~1 case in the last year have discovered it because of
OpenStack's gerrit :)).

So, there's probably no prefect solution. There is not a 1-to-1
profile-to-identifier mapping, and it's probably not feasible for there
to be such a restriction. I think the best we can sensibly do is provide
UI to select the primary identity, which is used as the delegated
identity that shows up on <https://launchpad.net/~someperson>.