Broken OpenID

[Anne Kathrine Petterøe <yo...@gmail.com>]

I was looking at the open Jira tasks for release 1.1.
Do we really want to support OpenID? With our enterprise focus and LDAP support with this release, I cannot really see a need for OpenID anymore. What do you think?

/Anne

Re: Broken OpenID

[Richard Hirsch <hi...@gmail.com>]

Yep - unless there are bugs associated with it.

I'll probably create a video on how to use it and post it on our new YouTube
channel when I've got a few minutes to spare.

D.

On Mon, Jun 14, 2010 at 2:12 PM, Anne Kathrine Petterøe
<yo...@gmail.com>wrote:

> So consensus is to keep OpenID, but not invest any more time in it?
>
> On 14. juni 2010, at 12.25, Richard Hirsch 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 <vd...@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
> >>
>
>

Re: Broken OpenID

[Anne Kathrine Petterøe <yo...@gmail.com>]

So consensus is to keep OpenID, but not invest any more time in it?

On 14. juni 2010, at 12.25, Richard Hirsch 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 <vd...@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
>> 

Re: Broken OpenID

[Erik Engbrecht <er...@gmail.com>]

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 <es...@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 <vd...@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/

Re: Broken OpenID

[Richard Hirsch <hi...@gmail.com>]

On Sun, Jun 20, 2010 at 7:14 PM, Ethan Jewett <es...@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 <hi...@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 <vd...@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
>> >
>>
>

Re: Broken OpenID

[Ethan Jewett <es...@gmail.com>]

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 <hi...@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 <vd...@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
> >
>

Re: Broken OpenID

[Richard Hirsch <hi...@gmail.com>]

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 <vd...@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
>

Re: Broken OpenID

[Vassil Dichev <vd...@apache.org>]

> 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.

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.

Vassil

Re: Broken OpenID

[Anne Kathrine Petterøe <yo...@gmail.com>]

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?

/Anne


On 7. juni 2010, at 10.38, Richard Hirsch wrote:

> Closed the old jira item and created a new one about adding OpenID URL
> to signup page (https://issues.apache.org/jira/browse/ESME-222).
> 
> D.
> 
> On Mon, Jun 7, 2010 at 10:13 AM, Richard Hirsch <hi...@gmail.com> wrote:
>> I fixed it last week. You can now login via OpenId but only if you
>> first signup normally and then add your openID URL to your profile.
>> Tested this and it works. What no longer works is trying to signup via
>> OpenID.
>> 
>> We could add the OpenID field to the signup form. We might then add
>> logic to the validation if openID is set, then password isn't
>> necessary.
>> 
>> On Mon, Jun 7, 2010 at 10:08 AM, Vassil Dichev <vd...@apache.org> wrote:
>>> If the code is already there and it doesn't take a lot of effort to
>>> maintain, why not?
>>> 
>>> I had the impression that OpenID worked, isn't this the case?
>>> 
>>> Vassil
>>> 
>>> 
>>> On Mon, Jun 7, 2010 at 11:05 AM, Anne Kathrine Petterøe
>>> <yo...@gmail.com> wrote:
>>>> I was looking at the open Jira tasks for release 1.1.
>>>> Do we really want to support OpenID? With our enterprise focus and LDAP support with this release, I cannot really see a need for OpenID anymore. What do you think?
>>>> 
>>>> /Anne
>>> 
>> 

Re: Broken OpenID

[Richard Hirsch <hi...@gmail.com>]

Closed the old jira item and created a new one about adding OpenID URL
to signup page (https://issues.apache.org/jira/browse/ESME-222).

D.

On Mon, Jun 7, 2010 at 10:13 AM, Richard Hirsch <hi...@gmail.com> wrote:
> I fixed it last week. You can now login via OpenId but only if you
> first signup normally and then add your openID URL to your profile.
> Tested this and it works. What no longer works is trying to signup via
> OpenID.
>
> We could add the OpenID field to the signup form. We might then add
> logic to the validation if openID is set, then password isn't
> necessary.
>
> On Mon, Jun 7, 2010 at 10:08 AM, Vassil Dichev <vd...@apache.org> wrote:
>> If the code is already there and it doesn't take a lot of effort to
>> maintain, why not?
>>
>> I had the impression that OpenID worked, isn't this the case?
>>
>> Vassil
>>
>>
>> On Mon, Jun 7, 2010 at 11:05 AM, Anne Kathrine Petterøe
>> <yo...@gmail.com> wrote:
>>> I was looking at the open Jira tasks for release 1.1.
>>> Do we really want to support OpenID? With our enterprise focus and LDAP support with this release, I cannot really see a need for OpenID anymore. What do you think?
>>>
>>> /Anne
>>
>

Re: Broken OpenID

[Richard Hirsch <hi...@gmail.com>]

I fixed it last week. You can now login via OpenId but only if you
first signup normally and then add your openID URL to your profile.
Tested this and it works. What no longer works is trying to signup via
OpenID.

We could add the OpenID field to the signup form. We might then add
logic to the validation if openID is set, then password isn't
necessary.

On Mon, Jun 7, 2010 at 10:08 AM, Vassil Dichev <vd...@apache.org> wrote:
> If the code is already there and it doesn't take a lot of effort to
> maintain, why not?
>
> I had the impression that OpenID worked, isn't this the case?
>
> Vassil
>
>
> On Mon, Jun 7, 2010 at 11:05 AM, Anne Kathrine Petterøe
> <yo...@gmail.com> wrote:
>> I was looking at the open Jira tasks for release 1.1.
>> Do we really want to support OpenID? With our enterprise focus and LDAP support with this release, I cannot really see a need for OpenID anymore. What do you think?
>>
>> /Anne
>

Re: Broken OpenID

[Anne Kathrine Petterøe <yo...@gmail.com>]

It kind of works, see Jira task #206 https://issues.apache.org/jira/browse/ESME-206
I was just wondering if we should spend the time maintaining the code if isn't working properly?

/Anne

On 7. juni 2010, at 10.08, Vassil Dichev wrote:

> If the code is already there and it doesn't take a lot of effort to
> maintain, why not?
> 
> I had the impression that OpenID worked, isn't this the case?
> 
> Vassil
> 
> 
> On Mon, Jun 7, 2010 at 11:05 AM, Anne Kathrine Petterøe
> <yo...@gmail.com> wrote:
>> I was looking at the open Jira tasks for release 1.1.
>> Do we really want to support OpenID? With our enterprise focus and LDAP support with this release, I cannot really see a need for OpenID anymore. What do you think?
>> 
>> /Anne

Re: Broken OpenID

[Vassil Dichev <vd...@apache.org>]

If the code is already there and it doesn't take a lot of effort to
maintain, why not?

I had the impression that OpenID worked, isn't this the case?

Vassil


On Mon, Jun 7, 2010 at 11:05 AM, Anne Kathrine Petterøe
<yo...@gmail.com> wrote:
> I was looking at the open Jira tasks for release 1.1.
> Do we really want to support OpenID? With our enterprise focus and LDAP support with this release, I cannot really see a need for OpenID anymore. What do you think?
>
> /Anne