incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: Broken OpenID
Date Sun, 20 Jun 2010 17:36:48 GMT
On Sun, Jun 20, 2010 at 7:14 PM, Ethan Jewett <esjewett@gmail.com> wrote:
> Just catching up here, but I seem to remember that originally if you tried
> to log in with an OpenID that was not associated with an account, it created
> an account and prompted you for several pieces of information, including the
> username you would like to use. Once you chose a username, it was not
> possible to change it, but the username was not defaulted to the OpenID.
> This was pretty nice functionality, but if we're going to container-based
> authentication anyway then I agree it's not worth recreating.
>
> Interesting related question: What is our behavior going to be if someone
> logs in with a valid container-based account that does not have a user set
> up in ESME? I think we would want to do something like what we originally
> did with OpenID: prompt for first name, last name, and username.

Excellent question - I hadn't thought about that. Maybe, we can have
common routine for both cases.

>
> Ethan
>
> On Mon, Jun 14, 2010 at 5:25 AM, Richard Hirsch <hirsch.dick@gmail.com>wrote:
>
>> I agree with Vassil. If I remember correctly, users created via OpenID had
>> their openid urls as their user ids which messed up our UI.
>>
>> The one idea I had was to add the OpenID to the sign-up page and created a
>> JIRA item for this. I looked at the code in the ProfileMgr that dealt with
>> this in the profile and decided that adding the openID to the sign-on page
>> was non-trivial and thus placed the jira item in the backlog.
>>
>> On Mon, Jun 14, 2010 at 12:16 PM, Vassil Dichev <vdichev@apache.org>
>> wrote:
>>
>> > > And my question still remains the same ;-)
>> > > Should we use time on this right now, or would it be easier to remove
>> the
>> > field in the UI for now?
>> >
>> > Sorry for not following up on this: I had the impression that OpenID
>> > worked as intended and the user is not supposed to create a user
>> > through OpenID. This would mean that the username would be
>> > autogenerated and currently you cannot edit the username. This is not
>> > a hard requirement, but do we want to make the username editable? It
>> > might make some implications for using existing pools, actions, etc.
>> > (not that they're bound to the username, but an attacker might use it
>> > for phishing/social engineering).
>> >
>> > Another drawback of OpenID user auto-creation is that a user will not
>> > have a password initially, and might not ever choose to set it. I'm
>> > not sure this is desirable, considering that OpenID might not always
>> > be available and there's no other way to log in.
>> >
>>
>> Good point  - the necessity of having two logins is feature :->
>>
>>
>> > Finally, from usability point of view if you think you have associated
>> > an OpenID URL with an existing account, but you're not, then logging
>> > in with OpenID will create a new account you do not want. This is
>> > especially tricky considering that we treat these as different URLs:
>> >
>> > http://host/path/
>> > http://host/path/index.html
>> > http://host.domain.com/path/
>> >
>> > So is OpenID actually broken? If it's not, there's no point in fixing it.
>> >
>>
>> I also agree with Anne that in the long-term, we will probably have
>> container-based authentication, so investing more time in OpenID probably
>> isn't ideal.
>>
>> >
>> > Vassil
>> >
>>
>

Mime
View raw message