From: Gianluca S. <gi...@gm...> - 2009-01-11 00:59:53
|
Hi, Seeing the commit from Victort for supporting OpenID prompted me to check how easy it would be to have a stand alone solution (i.e., not tied to a web service) based on the OpenID class provided by the Zend Framework: http://framework.zend.com/manual/en/zend.openid.html The result was very good: I was able in a couple hours to implement OpenID, just by adapting their example to our code. Conversely, I spent much more time was to modify the forms needed to support user interaction.... Right now, the code implements a workflow similar to the one you can find in sourceforge.net web site, that is: 1. the login form is augmented with a "OpenID" field 2. if the user fills the openid field, the login code looks for a user matching the id 3. if found, the openid authentication is started 4. if not found, the user is asked to chose between: 4.a login and a associate the openID to an existing user 4.b create a new user. The OpenID is storedin new field of the user_table, editable from the "My account" menu. If anyone wants to have a look, I can set up a working instance and/or provide a patch against master Cheers Gianluca PS. Right now, 4.a and 4.b are not finished, so to test openid it is needed to create an account first and then edit it to add the openid data. PPS. I determined the minimum subset of ZF classes to do the job, it is composed of few classes and about 200Kb of code -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: Victor B. <vb...@gm...> - 2009-01-11 06:46:16
|
Hi Gianluca, Thanks for doing this work. I've been discussing the OpenID implementation with Paul and here are the issues: 1. A user should be able to associate multiple OpenIDs with the same account. This is supported in the current implementation that is based on RpxNow. 2. Can we trust the email address associated with the OpenID? i.e. is it already verified? Should we send a confirmation email on sign up? 3. We should not match OpenIDs with existing accounts via email address, we should allow the users to create an association, e.g. like your suggestion below. Or there are alternative options. I would be interested in getting access to an instance with your changes / patch. Preferences related to implementation details: 1. Implement so that it is easy to migrate to a plugin when auth plug-ins are available. Paul was considering to work on this soon based on some previous work done by him and John. 2. The advantage of RpxNow is simpler implementation / no db changes. However, using Zend and talking no dependency would be fine. On Sat, Jan 10, 2009 at 4:59 PM, Gianluca Sforna <gi...@gm...> wrote: > Hi, > Seeing the commit from Victort for supporting OpenID prompted me to > check how easy it would be to have a stand alone solution (i.e., not > tied to a web service) based on the OpenID class provided by the Zend > Framework: http://framework.zend.com/manual/en/zend.openid.html > The result was very good: I was able in a couple hours to implement > OpenID, just by adapting their example to our code. > > Conversely, I spent much more time was to modify the forms needed to > support user interaction.... > > Right now, the code implements a workflow similar to the one you can > find in sourceforge.net web site, that is: > > 1. the login form is augmented with a "OpenID" field > 2. if the user fills the openid field, the login code looks for a user > matching the id > 3. if found, the openid authentication is started > 4. if not found, the user is asked to chose between: > 4.a login and a associate the openID to an existing user > 4.b create a new user. > > The OpenID is storedin new field of the user_table, editable from the > "My account" menu. > > If anyone wants to have a look, I can set up a working instance and/or > provide a patch against master > > Cheers > > Gianluca > > PS. Right now, 4.a and 4.b are not finished, so to test openid it is > needed to create an account first and then edit it to add the openid > data. > > PPS. I determined the minimum subset of ZF classes to do the job, it > is composed of few classes and about 200Kb of code > > -- > Gianluca Sforna > > http://morefedora.blogspot.com > http://www.linkedin.com/in/gianlucasforna > > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Gianluca S. <gi...@gm...> - 2009-01-11 23:22:39
|
On Sun, Jan 11, 2009 at 7:46 AM, Victor Boctor <vb...@gm...> wrote: > > I would be interested in getting access to an instance with your changes / > patch. and I'm now pushing these changes to: http://git.mantisforge.org/w/mantisbt/giallu.git?a=shortlog;h=refs/heads/openid so you can have a look at what's involved (and what is not finished) -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: Gianluca S. <gi...@gm...> - 2009-01-11 14:36:38
|
On Sun, Jan 11, 2009 at 7:46 AM, Victor Boctor <vb...@gm...> wrote: > > 1. A user should be able to associate multiple OpenIDs with the same > account. This is supported in the current implementation that is based on > RpxNow. Yeah, SF is doing the same (though I can't really understand why that's really useful). This can be implemented in different ways, the easiest would be to allow the openid field in the user table to be a comma separated list of OpenIDs. If needed, we can come up with a separate table storing the IDs and their association with the users. > > 2. Can we trust the email address associated with the OpenID? i.e. is it > already verified? Should we send a confirmation email on sign up? I think we can, every OpenID provider I registered with verify the email. However, it is completely up to us to decide if we want to revalidate the address. > > 3. We should not match OpenIDs with existing accounts via email address, we > should allow the users to create an association, e.g. like your suggestion > below. Or there are alternative options. I am not sure, the only site I use where openid is used for authentication purposes is sf.net, and they implement the manual association step. All the others are blogs where the openid is used to add comments instead of captcha or registration. > > I would be interested in getting access to an instance with your changes / > patch. Ok, my laptop is now online at http://giallu.selfip.org. You can register an new account and try it out; I'll leave it online for the next 12 hours, then it will be back again when I'm at home. I can't make anything more stable right now, since my home machine is dead... > > Preferences related to implementation details: > > 1. Implement so that it is easy to migrate to a plugin when auth plug-ins > are available. Paul was considering to work on this soon based on some > previous work done by him and John. Yeah. I need to note here that if we go the Zen_OpenID route, then the next logical step would be to try out the Zend_Auth component, which is sort of pluggable and support, out of the box, HTTP, Digest, LDAP and of course OpenID auth schemes. > > 2. The advantage of RpxNow is simpler implementation / no db changes. > However, using Zend and talking no dependency would be fine. I can see the value in the "no db changes" part, but overall I'm not sure about the "simpler implementation". Anyway, let's judge by yourself as soon as I manage to push this stuff somewhere... All in all, this means you are ok with replacing the rpxnow based solution? I'm asking because I am probably going to work elsewhere if this has no chance of being pushed now. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |
From: Manilal K M <ma...@ej...> - 2009-01-12 06:23:56
|
Quoting Gianluca Sforna <gi...@gm...>: > On Sun, Jan 11, 2009 at 7:46 AM, Victor Boctor <vb...@gm...> wrote: >> >> 1. A user should be able to associate multiple OpenIDs with the same >> account. This is supported in the current implementation that is based on >> RpxNow. > > Yeah, SF is doing the same (though I can't really understand why > that's really useful). This can be implemented in different ways, the > easiest would be to allow the openid field in the user table to be a > comma separated list of OpenIDs. If needed, we can come up with a > separate table storing the IDs and their association with the users. IMO, separate table for openIDs would make more sense , rather than separating it by commas within a single field. > > Yeah. I need to note here that if we go the Zen_OpenID route, then the > next logical step would be to try out the Zend_Auth component, which > is sort of pluggable and support, out of the box, HTTP, Digest, LDAP > and of course OpenID auth schemes. Can we have an option for composite authentication? I have seen it in Moodle. In moodle it's also possible to specify the order in which to search for a authentication database. -- Manilal K M eJyothi Services http://www.ejyothi.com |
From: Victor B. <vb...@gm...> - 2009-01-12 06:58:40
|
Replies inline. On Sun, Jan 11, 2009 at 6:36 AM, Gianluca Sforna <gi...@gm...> wrote: > On Sun, Jan 11, 2009 at 7:46 AM, Victor Boctor <vb...@gm...> wrote: > > > > 1. A user should be able to associate multiple OpenIDs with the same > > account. This is supported in the current implementation that is based > on > > RpxNow. > > Yeah, SF is doing the same (though I can't really understand why > that's really useful). This can be implemented in different ways, the > easiest would be to allow the openid field in the user table to be a > comma separated list of OpenIDs. If needed, we can come up with a > separate table storing the IDs and their association with the users. [Victor] This is useful if users change OpenID providers. I would rather have a mapping table with id, openid_url, user_id. > > > > > 2. Can we trust the email address associated with the OpenID? i.e. is it > > already verified? Should we send a confirmation email on sign up? > I think we can, every OpenID provider I registered with verify the > email. However, it is completely up to us to decide if we want to > revalidate the address. [Victor] The risk is if an attacker create their own provider. I think in this case we are exposed. The question is whether we want to re-validate email address or have a set of trusted providers. I think we will be more OpenID compliant if we go with the former. > > > > > 3. We should not match OpenIDs with existing accounts via email address, > we > > should allow the users to create an association, e.g. like your > suggestion > > below. Or there are alternative options. > > I am not sure, the only site I use where openid is used for > authentication purposes is sf.net, and they implement the manual > association step. All the others are blogs where the openid is used to > add comments instead of captcha or registration. > > > > > I would be interested in getting access to an instance with your changes > / > > patch. > > Ok, my laptop is now online at http://giallu.selfip.org. You can > register an new account and try it out; I'll leave it online for the > next 12 hours, then it will be back again when I'm at home. [Victor] The main issue with your interface is that the users don't get any clue of what they need to type. Two main challenges: 1. What are OpenIDs? For example, a lot of people won't know the Yahoo, Gmail, etc are OpenIDs. 2. What is the mask to use? One of the advantages of RpxNow is that it provides a widget that gives hint about supported providers that creates a url from a user name. Other sites provide a list of the famous providers next to the login with username.myopenid.com or whatever. Checkout http://stackoverflow.com which uses RpxNow as well as providing the hints. When I tried your site I got the following: SYSTEM WARNING: Zend_Loader::include_once(Zend/Uri/Http.php) [ zend-loader.include-once <http://giallu.selfip.org/zend-loader.include-once>]: failed to open stream: No such file or directory SYSTEM WARNING: Zend_Loader::include_once() [function.include<http://giallu.selfip.org/function.include>]: Failed opening 'Zend/Uri/Http.php' for inclusion (include_path='/var/www/mantis/mantisbt-public/core/:.:/usr/share/pear:/usr/share/php') > > > I can't make anything more stable right now, since my home machine is > dead... [Victor] That's fine, let us know when a more stable one is available. > > > > > > Preferences related to implementation details: > > > > 1. Implement so that it is easy to migrate to a plugin when auth plug-ins > > are available. Paul was considering to work on this soon based on some > > previous work done by him and John. > > Yeah. I need to note here that if we go the Zen_OpenID route, then the > next logical step would be to try out the Zend_Auth component, which > is sort of pluggable and support, out of the box, HTTP, Digest, LDAP > and of course OpenID auth schemes. [Victor] I agree that it would be best if we design the auth plugin support and provide a plugin that works with Zend_Auth or Pear one. This way we get support for multiple auth. This will also mean that we have the right events to support plugins that implement such auth mechanisms without dependency on such frameworks. > > > > > > 2. The advantage of RpxNow is simpler implementation / no db changes. > > However, using Zend and talking no dependency would be fine. > I can see the value in the "no db changes" part, but overall I'm not > sure about the "simpler implementation". Anyway, let's judge by > yourself as soon as I manage to push this stuff somewhere... [Victor] I think it is less risk to have a raw open id support (i.e. the approach you are taking). However, we have to provide the hints to the user as I suggested above. I see the widget as a major usability improvement. > > > All in all, this means you are ok with replacing the rpxnow based > solution? I'm asking because I am probably going to work elsewhere if > this has no chance of being pushed now. [Victor] Yes, I'm ok with moving towards a raw implementation. My target is for 1.2 to have Open ID support. I believe RpxNow can give us support to more than OpenID, but this can be added as a plugin later. I see that OpenID will help remove the barrier for entry for a lot of users to try MantisBT / report issues for us and projects using MantisBT as their bug tracker. > > -- > Gianluca Sforna > > http://morefedora.blogspot.com > http://www.linkedin.com/in/gianlucasforna > > > ------------------------------------------------------------------------------ > Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Gianluca S. <gi...@gm...> - 2009-01-12 09:29:55
|
On Mon, Jan 12, 2009 at 7:58 AM, Victor Boctor <vb...@gm...> wrote: > [Victor] This is useful if users change OpenID providers. I would rather > have a mapping table with id, openid_url, user_id. Does it means you'd allow a single OpenID to authenticate more than user in the tracker? >> >> > >> > 2. Can we trust the email address associated with the OpenID? i.e. is >> > it >> > already verified? Should we send a confirmation email on sign up? >> I think we can, every OpenID provider I registered with verify the >> email. However, it is completely up to us to decide if we want to >> revalidate the address. > > [Victor] The risk is if an attacker create their own provider. I think in > this case we are exposed. The question is whether we want to re-validate > email address or have a set of trusted providers. I think we will be more > OpenID compliant if we go with the former. I'd probably need to read OpenID specs a bit more, but IIRC the "Open" part includes having the freedom to be your own provider. What kind of "attack" are you trying to address? >> >> Ok, my laptop is now online at http://giallu.selfip.org. You can >> register an new account and try it out; I'll leave it online for the >> next 12 hours, then it will be back again when I'm at home. > > [Victor] The main issue with your interface is that the users don't get any > clue of what they need to type. Two main challenges: > 1. What are OpenIDs? For example, a lot of people won't know the Yahoo, > Gmail, etc are OpenIDs. > 2. What is the mask to use? One of the advantages of RpxNow is that it > provides a widget that gives hint about supported providers that creates a > url from a user name. > Other sites provide a list of the famous providers next to the login with > username.myopenid.com or whatever. > Checkout http://stackoverflow.com which uses RpxNow as well as providing the > hints. Agreed, but of course the current implementation was not meant to be exhaustive. We can surely improve the user experience before pushing it. > When I tried your site I got the following: > > SYSTEM WARNING: Zend_Loader::include_once(Zend/Uri/Http.php) > [zend-loader.include-once]: failed to open stream: No such file or directory > > SYSTEM WARNING: Zend_Loader::include_once() [function.include]: Failed > opening 'Zend/Uri/Http.php' for inclusion > (include_path='/var/www/mantis/mantisbt-public/core/:.:/usr/share/pear:/usr/share/php') >> obviously I FAIL... I run some git command in the wrong directory and nuked part of the classes. Sorry for that, it should be fixed now. >> Yeah. I need to note here that if we go the Zen_OpenID route, then the >> next logical step would be to try out the Zend_Auth component, which >> is sort of pluggable and support, out of the box, HTTP, Digest, LDAP >> and of course OpenID auth schemes. > > [Victor] I agree that it would be best if we design the auth plugin support > and provide a plugin that works with Zend_Auth or Pear one. This way we get > support for multiple auth. This will also mean that we have the right > events to support plugins that implement such auth mechanisms without > dependency on such frameworks. >> We discussed the issue with John on IRC, see: http://www.mantisforge.org/irclogs/%23mantishelp.2009-01-11.log.html Basically, the plan would be to base our design on the Zend_Auth one (I need to investigate further, but at first glance it looks like pretty simple to understand and use). We would use Zend_Auth to provide the basic auth methods (HTTP Basic/Digest and DB based), then design the plugins around that andfinally implement LDAP and OpenID as plugins. At this point, we will have a fairly complete set of auth stuff, easily pluggable with anything you can think of. > > [Victor] Yes, I'm ok with moving towards a raw implementation. My target is > for 1.2 to have Open ID support. Ok, then I'll work more on that so we can finish it up and move on... Of course if anyone is interested in helping, feel free to ping me here or in the IRC channel. -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna |