When I started my new job last year, one of the most exciting things about it was that we would be writing several applications from the ground up, and that it would be my job (in part) to decide which platforms to use to write these applications. I’ve been working for roughly five years writing Java/J2EE Web applications, but when the time came to pick a platform for this project, I chose Ruby on Rails. The last product I built was a huge pile of business logic with a very thin Web services layer on top. For that one I’d probably choose to use Java again. These applications are mostly content management tools, and play perfectly into the strengths of Ruby on Rails.

Anyway, today we launched our first small Ruby on Rails application — a piece of the identity management stuff I was talking about awhile back. It’s a simple account management application (sign up, reset password, update profile, etc) which stores users in its own database and to an LDAP server’s database. We already have a couple of internal PHP applications, several MediaWiki installs, and a Jabber server that are are authenticating users via LDAP, so this gets us most of the way toward having centralized account management, although we will probably add a Web service for authentication for some applications that are yet to be written as well.

We already had some accounts on a different LDAP server, so I had to migrate those users to the new database. This was one of the places where the decision to use Ruby on Rails really paid off. Most people who are new to Ruby think of it in the Rails context, but it originated as a saner way to do the stuff Perl does. Given a flat file of old accounts, parsing the data with Ruby was really simple, as I expected. The cool thing was that by including my Rails environment configuration, I could load up the entire Rails environment and take advantage of it from my script as well. That meant that I could use ActiveRecord, the object-relational mapping tool in Rails, to perform all of my database tasks, and the ActionMailer, the mail component I was already using in my Web application, to send emails to all of the users to let them know that their passwords had been changed. In other words, I was able to use lots of framework code outside its expected context and save a lot of time doing so.

After migrating the accounts, I realized that I had not created entries in a table called ldap_entries. Users must have an entry in that table to authenticate against the LDAP server. Fortunately, my user model already had a method called generate_ldap_entry that’s called when users sign up via the Web interface, so to add the entries for every user in the database I was able to use a two line script:

require File.expand_path(File.dirname(__FILE__)
+ "/../config/environment")
User.find_all.each { |user| user.generate_ldap_entry }

That’s real power.