Rails Plugins

Comments and changes to this ticket

• 

  Joshua Peek May 5th, 2008 @ 03:59 PM

  • → Assigned user changed from “” to “Joshua Peek”
  • → State changed from “new” to “invalid”

  The "ruby-openid" already does this verification. And if I'm mistaken, you should let the openid guys know so they can make this change in the gem.

• 

  Nathaniel Bibler May 5th, 2008 @ 04:55 PM

  It's not so much a problem with the inability to run the OpenID verification itself (that seems to work just fine with ruby-openid 2.0.4), but rather how the open_id_authentication plugin handles the data when it is returned, I believe.

  Sending a request for authentication to Yahoo! (which similar to sending a request to AOL's OpenID) will allow anyone with a Yahoo! account to authenticate against it. This is supposed to make it easier for "non-tech" people to use OpenID by ultimately allowing them to say, "Yes, I use OpenID, and it is 'aol.com'". AOL will then let them sign in with their AOL credential, and then report back to the RP the actual identity (not 'aol.com' but 'http://me.aol.com/blah', for instance).

  This is unlike the OpenID 1.0 standard, where openid.nathanielbibler.com could only be authenticated by myself. In 2.0, https://me.yahoo.com/nathanielbi... could be authenticated by myself, or even by you with a valid Yahoo account. The difference at this point is that Yahoo will report back my identity if I authenticate, or your identity if you authenticate through them. And further, even if I authenticate against my own identity url, the RP isn't guaranteed to receive an identical identity url back post-verification.

  The problems seem to arise when attempting to match validated identities against data stored in the local application database. The identity_url given by the open_id_authentication authenticate_with_open_id method does not necessarily match anything known in the database.

  Whether this is a coding issue with the plugin, or an implementation issue specific to updates with the OpenID 2.0 change, I feel it's more a problem with the plugin (either code or documentation on how to properly use it in 2.0) than with the ruby-openid gem, which appears to authenticate properly.

• 

  Joshua Peek May 5th, 2008 @ 06:59 PM

  This is unlike the OpenID 1.0 standard, where openid.nathanielbibler.com could only be authenticated by myself. In 2.0, https://me.yahoo.com/nathanielbi... could be authenticated by myself, or even by you with a valid Yahoo account. The difference at this point is that Yahoo will report back my identity if I authenticate, or your identity if you authenticate through them. And further, even if I authenticate against my own identity url, the RP isn't guaranteed to receive an identical identity url back post-verification.

  Interesting. I would expect the gem to verify the returned identity url then.

  The problems seem to arise when attempting to match validated identities against data stored in the local application database. The identity_url given by the open_id_authentication authenticate_with_open_id method does not necessarily match anything known in the database.

  Isn't that the expected behavior. I want to search the db for the identity url "aol.com/me" not "aol.com".

  Whether this is a coding issue with the plugin, or an implementation issue specific to updates with the OpenID 2.0 change, I feel it's more a problem with the plugin (either code or documentation on how to properly use it in 2.0) than with the ruby-openid gem, which appears to authenticate properly.

  The plugin is simply a wrapper around the gem. It is not supposed to implement any of the OpenID validation specs, this is the job of the gem.

• 

  Joshua Peek May 5th, 2008 @ 09:13 PM

  • → State changed from “invalid” to “open”

  Patch: http://github.com/nbibler/open_i...

  Thanks for the patch, code really helps explain. I'm going commit it, but you can you just explain how "display_identifier" differs from "endpoint.claimed_id" for the CHANGELOG. I think I understand but still a little unclear.

  This will still return the "expanded" yahoo ids, correct? (yahoo.com => flickr.com/people/josh, etc)

• 

  Nathaniel Bibler May 5th, 2008 @ 09:18 PM

  It should, yes. The whole thing is a little weird coming from the OpenID 1.X spec.. but I'll updated the changelog and try to explain what I can.

• 

  Joshua Peek May 5th, 2008 @ 09:37 PM

  • → State changed from “open” to “resolved”

  Awesome!

  Sorry about the initial confusion.

• 

  Nathaniel Bibler May 5th, 2008 @ 09:42 PM

  The following explanation is based on the ruby-openid 2.0.4 codebase, and the differences between the OpenID 1.1 and 2.0 specifications, so please bare with me if there have been changes since.

  The original open_id_authentication plugin relied heavily on the 'openid.claimed_id' value coming back from the OpenID Provider (OP). This was fine when we were using OpenID 1.1 and earlier specs. As per the definition, this value was not to be altered and could service as a common, agreed upon identifier. I provide my claimed_id (or 'identity_url') to the application, the application validates it against the OP, and if everyone agrees, the user is allowed access.

  With OpenID 2.0, however, this has changed. OPs are now allowed to alter the claimed_id value in their response. There are several reasons for them to do this, which I won't go into here, but it is important to note that it can be (and already _IS_, see Yahoo and AOL) done. So, just because I tell you my identity is 'https://me.yahoo.com/nathanielbibler', the Yahoo OP will will respond that no, my true identity is 'https://me.yahoo.com/nathanielbibler#95521' but this user will recognize it as 'https://me.yahoo.com/nathanielbibler'.

  And, while that seems easy enough, take a further example from AOL. I could tell you that I use OpenID, and my identifier is 'aol.com.' You should then redirect me to aol to sign in, where the AOL OP will respond back with the correct identity and displayable values.

  So, here is where the updates to the ruby-openid gem come into play. The OpenID::Consumer::Response instance has two methods attached to it, named 'identity_url' and 'display_identifier'. These two methods should return back the two values mentioned above.

  As per the documentation, we should use the identity_url value whenever making comparison tests. So, this is the true value of the OpenID identifier according to the OP, and should not henceforth change.

  However, to respect the current implementation base, the patch provided utilizes the display_identifier, which follows more closely with what is currently expected from the open_id_authentication plugin. i.e. does the provided identifier match what I have in the database which was provided by my user?

  With the OpenID 2.0 spec, a user will likely never be able to remember, or for that matter, may never even know their true identity url, according to their OP.

  So, the long term solution to this is to alter the way we show people how to use OpenID from within their applications. They should first ask for an identity url. This url should then be authenticated. And then those values which are returned from the response should be stored as the true identity_url to utilize in the future. Of course, the display value should also be stored to keep the identity recognizable to the end user from the UI.

  Fun, eh?

  I'm sure bits and pieces of this are probably not 100% accurate and anyone that knows or understands any more about this should chime in, but I believe that generally sums it up.

• 

  Nathaniel Bibler May 6th, 2008 @ 04:33 AM

  I hope that made sense.

  My suggestion for a future direction with the plugin, to gain "full compatibility" with the ruby-openid gem and OpenID 2.0, is to modify the yields on the complete_open_id_authentication method to yield back both the identity_url and display_identifier and then update the documentation with examples and explanation on how to properly use both.

  Interface changes are always a pain, though. And, it would potentially wreck existing apps that are utilizing the old identity_url (which would now be considered the display_identity) and expecting them to still match.

• 

  Nathaniel Bibler July 13th, 2008 @ 06:44 AM

  • → Tag changed from “” to “openid patch plugin”

  The patch / resolving commit can currently be found at:

  http://github.com/rails/open_id_...