When you enter your serial number, you will be redirected to a website in order to fully register and activate your product. This website will require a new Autodesk login id – different from your student community login id.

Apparently, it isn’t enough to remember Yet Another Set Of Login Credentials(tm) for any given website I want to use semi-regularly (Sorry, NY Times, but your login wall works quite well in keeping me from perusing your news section), but AutoDesk requires bloody two of them. Which is rather obvious nonsense. Even my college manages to provide a SSO behind the scenes. Too bad my college uses AutoCAD, too, so I’m pretty much stuck with it. Awesome.

BTW, AutoDesk: Acronyms are capitalized. It is “ID”. Otherwise, I’ll call it Autodesk cad, m’kay?

And a 13 month limit on an install is rather ridiculous, considering that college takes at least 3 years, and that I could, you know, use a torrent instead. Great job in punishing me for being honest. Gotta love market leaders. Always the same crap.

Also, an explanation for the long silence: I was busy applying for college to get a mechanical engineering degree. That took up a lot of time, and cost me a lot of nerves, so I couldn’t sit down to properly write something.

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.