esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Engbrecht <erik.engbre...@gmail.com>
Subject Re: Broken OpenID
Date Sun, 20 Jun 2010 17:45:03 GMT
Just a thought...I had a few pet peeves about "enterprise applications"
that:

1. Use a separate username/password from my network login
2. Use the same username/password, but require me to enter it (I'm already
logged into my computer)
3. Use negotiate based authentication, but the require me to provide my
personal data (name, phone #, etc) that's already in about a dozen places
already

Ideally a user should never have to enter his username, password, or basic
personal data that's most likely available via LDAP.  In some enterprises
such things may be problematic due to "security restrictions" and plain old
bureaucracy, so fallbacks are needed, but it should be the default.

On Sun, Jun 20, 2010 at 1: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.
>
> 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
> > >
> >
>



-- 
http://erikengbrecht.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message