OpenID Support

Goal

Bugs

People

ChuckHagenbuch is interested in this project, and can provide expert support on Horde's authentication layer.

Description

Horde Implementation Plan

Horde_Openid_Server
Horde_Openid_Consumer

Horde_Auth_Openid -> authenticate with openid server, but generate a local id for users in another horde backend? or have an openid_users table? still need to integrate that with regular auth to allow lookups, prefs, etc.

horde_user_map table - map from any kind of user_id to a numeric horde_user_id that can be used to identify either external (openid, whatever) or internal (Horde_Auth driver) users, and provide a simple numeric value for use in other applications SQL tables. have different versions of horde_user_map if necessary for different kinds of userids, but with openid, probably always going to need a varchar(255) anyway.

Notes

As posted a few months back, I had started working on a PHP5 OpenID library that I wished to port to the framework since it seemed a reasonable addition given our web app focus. Given the complexity of OpenID as a distributed authentication service there are numerous components. Each by itself is actually not that hard, most of the problem is putting them together with a solid set of integration tests.

These include wrappers for large integer (> 32 bits) libraries since bcmath alone is awfully slow for this compared to gmp, cryptographic algorithms, and even a separate extensible web service (already proposed on the wiki). The list of possible sub-components that could feasibly get started with include:

An actual Zend_Service_Openid would need all of the above as well as general file parsers. I was looking for an opinion as to whether these are acceptable as individual proposals. It seems to make sense rendering OpenID into its reusable constituent parts rather lumping everything (and inevitably burying/hiding it) into the Openid namespace. I don't want to go spamming the wiki with 6+ proposals until I get a little feedback either :).

JanRain code:
I dug through the JanRain code quite a bit, and it's a bit bloated and sloppy, but I think that's just a side-effect of the library having been ported to a number of different languages, and clearly PHP wasn't the original. You might also be interested in Wez's much simpler code:

Unless you're in an environment where you can apply his patch, you can only implement the dumb mode (or do all of that big number math in PHP, which seems wasteful and error-prone). I was hoping the JanRain library would just work, since Wez's patch won't be an option for most people until the next public release of PHP.