Coldfusion OpenID Consumer Actionpack for ModelGlue

For those of you who haven’t been listening, OpenID seems to be hitting a tipping point lately — with the developer/tech savvy crowd that is. ClaimID reported 10,000 users a month ago, OpenID posts on Digg have hit the homepage three times in the last week too! Once for a screencast showing some openID logins , another by SixApart about it’s growing momentum and the one that I added to my blog right away about How to turn your blog in to an OpenID . It’s too early to see the results of this saturation to the community overnight (except perhaps if you’re an openID Server), but people and developers are taking notice. As a long time Livejournal user, I’d been exposed to it, but only recently started to appreciate it myself. Well the Coldfusion community is taking notice too! There are a handful of full consumer/clients out there , but none for Coldfusion. The java one is open source though, so writing a Coldfusion wrapper for it wouldn’t be reinventing the wheel, and assuming the interface stays the same, we’d benefit from all their future development. But in the meantime, I’ve been messing around with creating an OpenID consumer in Coldfusion as a ModelGlue Actionpack. It’s coming along nicely so far, but it’s far from completed or polished. The actual coding required to make an OpenID Consumer is surprisingly easy though:

• The user enters their openID login. This can be either a placeholder page from their openID server (like http://adamfortuna.pip.verisignlabs.com ) or it can be anywhere else that delegates to a server (like adamfortuna.com). What’s entered can be prefixed with http://, or not.
• The webserver the user is on (from now on called the Consumer) reads in the page they entered and parses out the head for a tag with a “rel” of “openid.server” which should be a valid url.
• The consumer crafts a URL using the openid specifications directing to this URL. Basically the webserver will include the mode of the request, which fields to request (like username, fullname, date of birth, etc), which of those are required and which are optional. Also in this URL we give a “return to” url, which is where the OpenID will send the user after they’re done.
• The consumer sends the user to this URL, either by relocating or by a javascript redirect.
• The user is now on the OpenID servers site. They must login if they aren’t already. After that they are prompted to verify they want to allow the referring consumer to access the information they requested by allowing it.
• The OpenID Server redirects the user back to the “return to” location provided by the consumer with a long URL that includes all the information the user allowed us access to, if they allowed us access to anything. This will a lot of fields in the URL if we’re requesting a lot of information.
• The consumer reads in the url.openid.mode, if it’s “cancel” the user didn’t allow access, if it’s “id_res” the server granted us access. If they did grant access, there will also be a cvariable with a comma separated list of fields the openid server returned.
• The consumer loops through these fields in “url.openid.signed” and generates one last request back to the OpenID server with everything that was sent over. This step is basically a double check from the consumer back to the server, since the previous step could have been sent by anyone. The destination of this request should be to url.openid.signed.
• The openID Server gives a success/failure message back and we’re confirmed one way or another!

That probably sounds like a lot of work, but each of the requests is extremely simple. It’s also stateless, so any request can happen at any time. The actionpack takes in a few coldspring parameters, such as what event to send the user to if they deny (cancel) or approve, which fields to make optional, which to make required, and the http timeout. Basically adding a message broadcast to any event of “openidVerify” is all that’s needed, assuming a field of “openid_url” is available (the openid standard for this form field name). You can read the actionpack install file for more details. After a successful lookup, the actionpack will throw a structure in the viewstate with all data provided by the OpenID server easily available. Screenshot below to make things easier. I’m still working on this myself, but would love to create a full server/client in Coldfusion. First steps taken! No zip’d up download at the moment, but it’s in my public repository under /modelglue/actionpacks/openid and /modelglue/modelgluesamples/openid.