On 01/20/2012 02:53 PM, William Grant wrote:
> 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 :)
Nope - but I need to get the ssh key from the launchpad account, and
once I've created that account, I need to be able to map their login
once they've logged in through the web. :) (It's a REALLY fun problem
domain, I promise)
>> 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>.
Ugh. Ok - that makes sense, although it makes me want to cry a little bit.
I suppose a launchpad api patch to allow getting the OpenID identity
which will show up on <https://launchpad.net/~someperson> will take
about as much time as a patch to gerrit to support group extension?
On 01/20/2012 02:53 PM, William Grant wrote: time, not before. time, because gerrit has
> 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-
>>
>> I can't just look at things at authentication-
>> 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 :)
Nope - but I need to get the ssh key from the launchpad account, and
once I've created that account, I need to be able to map their login
once they've logged in through the web. :) (It's a REALLY fun problem
domain, I promise)
>> That having been said, it may be the case that a user has more than one but-not- true-consumers like to-identifier mapping, and it's probably not feasible for there /launchpad. net/~someperson>.
>> 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-
> 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 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:/
Ugh. Ok - that makes sense, although it makes me want to cry a little bit.
I suppose a launchpad api patch to allow getting the OpenID identity /launchpad. net/~someperson> will take
which will show up on <https:/
about as much time as a patch to gerrit to support group extension?
/me cries in the corner