Automating User Registrations with OpenID and Spring Security 3.0 - Part 1

Having a few days of vacation is nice. Besides spending some precious time with my family, it also gave me some time to work on jRecruiter. I upgraded Spring Security to the final 3.0.0 version, which was released just a few days ago.

The upgrade process was relatively painless, though it is not a simple Jar drop-in as the packages of many of the classes changed. But it was fairly straight-forward.

The biggest hassle, was upgrading Jasypt as the latest released version is not playing nice with Spring Security 3.0, yet. But the code is already committed to Jasypt's source code repository, and with minor modifications, I was able to compile a custom version.

But while I was looking through the changes of Spring Security 3, I started reading a little bit more about its support for OpenID.Which then let to the question, whether there is a good use case for OpenID in my home project.

Places where I saw the use of OpenID are:

• https://www.plaxo.com/signin
• http://stackoverflow.com/

Here is actually a pretty good blog post regarding OpenID:

http://www.codinghorror.com/blog/archives/001121.html


Security Concerns

Then of course, there are also a few security concerns regarding allowing for OpenID authentication:

• http://serverfault.com/questions/7005/is-there-a-danger-in-fake-openid-providers
• http://stackoverflow.com/questions/182258/are-there-any-security-risks-associated-with-me-using-openid-as-the-authenticatio
• http://www.identityblog.com/wp-content/images/2008/02/OpenID/Normal/OpenIDPhish.html
• http://stackoverflow.com/questions/86090/openid-providers-what-stops-malicious-providers

 If that's not enough:

• http://stackoverflow.com/questions/tagged?tagnames=openid&sort=votes&pagesize=50

Thus, while I probably wouldn't use OpenID for a banking application, I feel it is a nice fit for my home project, it is used by local recruiters to post job postings. Up to this point every account holder had to provide her own username (email) and a password.

None of the information stored by jRecruiter is extremely sensitive and thus, OpenID might actually help improve the user experience of people posting jobs through the system.  Over the past few years I saw a common issue that account holder are unable to remember their password, or even their username (which made me to change over to more of a email-based username approach). Ultimately, there were quite a few duplicate registrations in the past.

An interesting question though is, is it advisable to restrict access to a limited amount of OpenID providers? (Such as myOpenID, Google or Yahoo)

Use Case

Well, this is were things are getting interesting, OpenID does not only define the notion of pure authentication but it can also gives you access to various pieces of your OpenID profile (e.g. first name, last name, email address etc.). This feature seems to vary, though, between providers (Have to see how that works out)

Thus, for jRecruiter I envision the following use case. When a user starts the login process:

1. she or he has a choice of either loggin in the traditional way using a username/password combination or 
2. by selecting the OpenID route. 
3. If the user logs in via OpenID and the authentication succeeds, but the user account within jRecruiter does not exists, yet, then the potential user is redirected to the registration pages and the fields of the registration form shall be pre-populated (as much as possible) using inforamtion from the user's OpenID profile. 

In my next blog installment I would like to give you some insights of how I created a first draft implementation using Spring Security 3.0. Keep in mind that this is an ongoing (learning) process...Thus, if you see issues, let me know.

Continue with part 2.