OMG, OpenID — how do I do it?

The concept is still new, yet new sites pop up every day supporting the technology. There is plenty of chatter on various blogs and mailing list about integrating with OpenID, yet there are not really a lot of examples on how to do things as a best practice.

When we decided to turn Crowd into an OpenID server application (end of May release), one of the first things we realized was that we needed a relying-party application to test our server with.

When we finished reviewing the specification and deciding on what we though would be best path to implementation we took a serious look at the various APIs to see which one would match up to our core feature needs.

Both projects are hosted on code.google.com which is a plus if you want to check them out because you already have an account so it is quick and easy to start integrating with the project.

Within minutes you quickly see there is a larger community around the OpenID4Java.org project.

Recently we purchased the openid4java.org domain and setup a redirect for the project as part of a larger effort to maven 2 friendly the project. A build server has also been added, and you can review the code though the Fisheye source code browser. The original code was developed by Sxip, who are one of the major drivers of the OpenID initiative.

After laying out our common framework stuff we were ready to build an OpenID login prompt:

One of the things that we added was a dynamic attribute exchange request builder. This way you can send request for anything and see how your server responds to the messages. With our server we are building a profile editor that highlights which attributes are required by the relying-party along with those that are optional. I will share some screenshots of this in a later post.

After the relying party client directs the user to the server for an authentication check we are sent back to the server with the following:

Looking at the image above you can see the request attributes are passed back to the relying party to do with as they wish. If you look in the upper right corner of the screen you can see we display the user’s full name and identifier as part of their authentication.

So how did we do it all?

Like I said we are going to be shipping this relying party application including code with the next major release of Crowd, but until then here are some code examples which are all based on OpenID4Java…

The Login Action sets up a basic authentication request that is passed off to a servlet that sends out the request to the Open ID provider. This is done so that multiple things like javascript can initialize an authentication request:

To determine if the user is authenticated we coded a servlet filter to check if the OpenIDPrincipal object is in session for the user. If the object is not in session, the authentication is considered invalid and the user is redirect to the login prompt: