I am lazy. That's why I like J2EE

No, really. Without J2EE, I wouldn't have access to Glassfish, with its wonderful autodeploy directory to, well, autmatically delpoy applications on it.

Without Java, I wouldn't be able to use JRuby.

And neither would I be able to use Warbler to create .war-files for drag and drop deployment.

In the span of 30 minutes (half of which is related to my underspec'd development environment), I was able to deploy a Rails application.

First, you need to setup your Rails application for use with JDBC. In Rails 2.0 it is as easy as this database.yml:

development:
host: localhost
adapter: jdbc
driver: com.mysql.jdbc.Driver
url: jdbc:mysql://localhost:3306/application_db
username:
password:

With the Warbler gem, you can easily create a war file:

jruby -S warble war

To fine-tune your configuration (if Warble's defaults aren't as good for you as they could), just run

jruby -S warble config

You can edit the resulting config\warble.rb for some fine tuning (I'll have to look into it, for example how to tell it to use a specific JRuby version).

Once you are ready to create your .war-file:

jruby -S rake war:standalone:create

Thsi creates a war file inculding the JRuby runtime. Drop into your domain's autodeploy folder, and wait until Glassfish is done deploying it. Done. You have a working, deployed, and automagically scaling Rails application. No need to herd a pack of Mongrels, futy with mod_proxy, or anything else. Wonderful.

BUT there is one issue you migth have (whcih is unrelated to Ruby, JRuby, or Glassfish):

It is possible that your Rails app throws the following exception:

No :secret given to the #protect_from_forgery call. Set that or use a session store capable of generating its own keys (Cookie Session Store).

Don't fret. Either use the correct security, or change your app/controllers/application.rb so it looks like this:

protect_from_forgery :secret => 'a_really_long_pseudo_random_hash_thing'

Simply remove the comment in front of the :secret. Done. Enjoy the bonus you just ensured for yourself, since you avoided at least a day of additional deployment and configuration, and/or learning capistrano.

P.S.: Still working on the comparison of OpenID and CAS for Ruby, so this is a bit of filler content.

A case for CAS

A couple of days ago, I talked about the limited options of SSO on the Ruby side of things. This turned out to be a bit of a mistake. In fact, the two viable SSO solutions are viable, and feature rich, providing what you need on the authentication server's side, as well as the client's side.

The issue was more that there are only these two options in the first place.

However, I'm going to take a deeper look at these two options. I'll do this in three articles, focusing on RubyCAS client and server first, OpenID client and server second, and comparing these against each other in the last episode.

Now, without further ado, a look into CAS.

CAS is Yale's solution to the SSO problem. It provides a client/server architecture, allowing each application to authenticate users against a single server.

Matt Zukowski (his RubyForge profile) implemented the Ruby variants of the Central Authentication Service Protocol (short CAS), both on the server side (RubyCAS server), and the client side (RubyCAS client).

Clientèle dealings

The client simply enables to authenticate against a server implementing the CAS protocol. That's it. Well, not quite.

Actually, a CAS enabled website hands authentication off to the CAS server login page, which checks the user's credentials, and redirects back to the requested webpage on successful authentication. The web application verifies that the user has, indeed, logged in, and works as expected.

The benefit of CAS for web-based SSO is, that any CAS-enabled application can use the ticket issued by the CAS server for authentication, as long as the server can read the cookie placed (so, it has to be the same URI that reads the cookie, not necessarily the same server).

Serving the greater good

The server works a bit different, and necessarily so. It takes the user's credentials, authenticates the user against the configured form of storage, and redirects back to the application requesting the authentication of the user.

For authentication, RubyCAS server brings three pre-configured Authenticators:

• CASServer::Authenticators::LDAP to authenticate against an LDAP directory service, and LDAP's cousin Active Directory gets its own Authenticator, called.
• Additionally, there is an SQL authenticator CASServer::Authenticators::SQL, which can use any SQL database that ActiveRecord can talk to.
• If none of these fit the bill, you can apparently use CASServer::Authenticators::Base to roll your own authenticator (the RDoc documentation is rather silent on the issue, and I haven't dug into the source code yet).

Concluding the obvious

As long as you use Ruby, you should be able to use RubyCAS client (you'll probably have to do some source code hacking if you don't use ActiveRecord for the RubyCAS server, though).

This should be of a great boon in any organization using the CAS system already. And the wealth of client options provided by the CAS ecosystem should make CAS an easy sell if you are looking for an SSO solution.

Kicking off the blog (and the project, too)

I promised myself, that I'd chronicle my efforts in developing a project from start to finish.

Well, this won't quite work out, since I already have the contract in hand. ;)

However, I'll write up what I am going to do, what I am doing, and the milestones reached. Well, a software development blog.


So, what's the project about?

I have to build a web-based Document management system.

Requested Features:

• Single Sign On
• Import documents from a network share
• Storage of metadata (an odd one in this case is, that physical locations have to be recorded, too, in case the government agency sending it cannot deal with electronic documents. Legal requirements are fun like that)
• Fortunately, no detailed tracking for SOX or other such regulations.

What's coming up

At first, I'll post progress about gathering requirements, proposals and recommendations of solutions for these requirements that go out to the client (after I've sent them, though).

After that, I'll report my progress with the application: What I did, why I did it, and what the challenges were.

And last but not least, I'll talk about the deployment of the application, and its maintenance.

So, what are you using?

The web application framework is going to be Ruby on Rails, the database back-end MySQL, the webserver will be Apache of some sort. What'll serve the Rails pages I don't know yet. Maybe Glassfish with JRuby, maybe mod_rails, possibly the classic Apache + Pack of Mongrels solution. We'll see when I get there.

My development OS will be Windows XP together with a Debian VM and a Kubuntu 8.04 installation as primary development OS.

The deployment will be on FreeBSD 5.4 (I know, I can't influence that, and neither can my client).

The approach I'll be using, even though I'm just one person, is a simple variant of Agile Development: Sprints, and loads of tests before I write the actual code.