Simple Single Sign-on Scheme

Single sign-on, or SSO, has become the Holy Grail of enterprise web applications and indeed, just like the mythical quest taken up by knights in medieval times, so there has yet to be found a unified standard to allow users to easily login across trusted web sites. The battleground is littered with the corpses of failed initiatives such as Microsoft's Hailstorm. The Liberty Alliance has churned out a number of PDFs but that seems to be the extent so far of their effort. On the open-source side, LID shows a lot of promise but without any major corporate sponsors, it's difficult to judge how successful it will be.

So lacking a working foundation to go on, I decided to strike out on my own. My requirements were simple in that a user would not have to create a separate account, the login procedure would not be a hindrance and above all it had to be secure. Too often in my dealings with vendors I've seen login schemes that easily allow a malicious user to spoof another user's identity and masquerade as somebody else on the site. With this lesson in mind, I went about detailing how it would all work.

We'll need to make some assumptions first. This scheme requires at least two entities. Entity A is the main organization, the one that holds all the users' account info. Entity B is a vendor that has agreed to interface with Entity A so that users will not have to create a second account to utilize Entity B's services. We must also assume that a user logs in with a user ID and password to access Entity A's site. That user ID must be unique and can be an email address or something auto-generated. As well, Entity A must have a service visible to the outside that can validate a user with their ID and password. The easiest method would be to have a web service that checks against an LDAP, RDBMS or some other data store.

The process begins when a user logs in to Entity A's site with their user ID and password. Once validated, a string is generated containing the user's ID and any other meta information Entity A may want to pass along to Entity B. This string is then encrypted using a key that has been pre-shared with Entity B. The resultant encrypted string is put through a Base64 encoding function and then URLEncoded to ensure that no characters are lost. This string is appended to a URL pointing to Entity B's site using an agreed upon CGI variable. This URL can be displayed as a link which the user can then click on.

Upon arriving at Entity B's site via the URL, the appended string is put through a reverse process (URLDecoded, Base64 decoded, decrypted using the same pre-shared key) and from that the user ID and any other attached meta information is made available. At this point, the user should see only an input field requesting their password. The other data can be put into hidden form fields which will be passed along when the user submits the form. When that form is submitted just the user ID and password will be passed back to Entity A but this time to a published web service to authenticate against. If the web service returns success, then the user is logged in. Otherwise, the user is routed back to Entity B's site but with an appropriate error message.

Simple really was the theme of this SSO implementation. Though it lacks the features of some of the more mature setups, it does have the advantage of being relatively easy to deploy. As well, the requirement that a user resubmit their password at Entity B's site means it can withstand a replay attack. And provided that employees at Entity A do not have direct access to users' passwords, they would not be able to login as another user either. You could increase the security even further by changing the pre-shared key every 90 days though even with the most basic Triple DES encryption a brute force attack would be impractical.

This scheme has been in production for over a month now on our member portal with no complaints or reported errors. This feat would not have been possible though without the help of some talented individuals. My colleague John K. proved invaluable when it came to brainstorming on this issue. And were it not for Mark H. at Workmode, my point man at the vendor, this project would not have gotten off the ground. Lastly, the encryption functionality was provided courtesy of DevX.com and was extremely easy to implement and use.

Please feel free to comment on this or email me if you have any questions.

Stepping over the stones

Yesterday I headed on up to what's affectionately referred to as the Business Center. It's where a lot of our hardware is located and also serves as offices for some of my colleagues who aren't quite in the same organization as me yet I have to deal with them regardless. They're nice enough folk but their mindset is a bit different than ours. They would argue that we don't necessarily "get" the grand plan while we would counter that our direct interaction with customers, as opposed to just fellow employees, doesn't allow us such a luxury.

So in the bi-weekly meeting that I attend up there I dropped the bombshell that I was planning on using Ruby on Rails in the rewrite of our web portal. Now understand that our current version, which was written before I started working there, is nowhere near what was promised to upper management in terms of capability and speed. Add onto that the enormous costs and the fact that the final product still hasn't been delivered and you can see how the people I answer to would be a bit anxious to get something rolling.

But naturally my colleagues didn't see it that way. Immediately a furor was raised over how I was going against the ingrained standards of the company and how difficult it would be to support an application written in an "alien" language. They made it seem as if it was Sean vs. The Holy J2EE Standard. Regardless, I know that the way to get Ruby through the system is not with direct confrontation. I did plenty of that at my last job and would much prefer to build bridges here. So I'm going the other route: I'm gonna charm 'em.

Upon return to the sanctuary of my cube I immediately set about creating accounts on my Linux box for each of those programmers who raised an objection. I then gathered all the helpful tutorials and links that I used when I was learning Ruby on Rails and put all the information into a nicely formatted, kindly worded email. The idea is that once they see the true power of this amazing framework they will better understand why I am going this route. I don't expect to make converts out of them overnight but I do hope that they drop their blind reluctance to it and give it the chance it deserves.

The cutting-edge and its place in production environments

The software developer constantly balances on the tip of a sword in their daily job. On the one hand they need to write production-quality applications in an efficient manner. But on the other hand, new tools and products are coming out every day that can help developers speed up their coding and also make their projects that much better.

These new tools however are not always ready for the production environment. I am especially wary of relying on products that are not v1.0 yet. But even those tools that are supposedly mature can introduce an untold number of bugs. When my former employer decided to go from ColdFusion 5.x to MX 6.0, the number of bugs doubled overnight. What had once worked in the old version, such as loosely-typed date formatting, no longer worked in the Java-powered strictly-typed 6.0. A minor revision a few months later helped in some places yet caused even worse bugs in others. But because in that few months time we had written applications that took advantage of all the new features there was just no going back.

In retrospect it was a good decision to upgrade however, certain steps should have been taken beforehand to analyze what changes a major upgrade would bring. This is why it is so important to have both a testing and development server in addition to a production server. With both of these tools we could have continued to develop in ColdFusion 5 while testing version 6 on a limited basis. When we made the switch to version 7, much more precaution was taken and though I was no longer employed there to see the final push I can only hope that the extra servers helped ease the transition.

Currently I am toying with the idea of using Ruby on Rails as the platform on which to build the next incarnation of my company's health portal. Whereas the accepted standard at the company is J2EE, recent articles have convinced me that the Ruby path is the true path though it may be harder in the short term with regards to management. In actuality, management at my company is fairly progressive and has never given me reason to think that they doubt in their programmers' abilities. And now that Rails is approaching the big 1, it will make adoption of it as an enterprise-capable platform that much easier.

Do not be afraid of something simply because it is new. The future is coming regardless of how we feel about it. Just as Java was once at the forefront of web application development, so I believe that Ruby is in that position today. But before you make that leap to a new technology make sure you have your contingency plan in order and are ready to put in some long hours if necessary.

Assumptions and their impact on software development

The rhetoric we usually hear about assumptions is that they "make an ass out of you and me". But I've heard another one that I think is more fitting in a lot of circumstances: assumptions are the mother of all fuck ups. This was proven beyond a doubt today when a vendor professed to us in a meeting that he had made certain assumptions about our product and that he would now need much more time to take these new 'facts' into account.

It's funny the way facts and assumptions work. For most, an assumption is a fact until it is proven otherwise. This is especially true in software design where there are so many variables that to take them all into account can cost an exorbitant amount of time. As such, programmers tend to focus only on the big ones leaving the smaller assumptions to sort themselves out. This can and often does spell disaster for large projects.

One of the ways to help minimize such dangers, besides increased communication between team members, is to decrease the complexity of a project. Remarkable advances have been made in software development to facilitate code testing without sacrificing budget, time or scope. On the Java side, I've been hearing great things about JUnit from my friends. But unfortunately for J2EE development, overall complexity still remains a huge hurdle to overcome, even for small to mid-sized projects.

Enter Ruby on Rails. This is the most ambitious project I've seen to date to try to tackle the problem of increasing complexity and overhead with regards to web application development. I've worked in many languages over the years: Perl, ColdFusion, PHP and Java just to name a few. When I saw what Ruby was capable of I didn't believe my eyes. But after I installed it and had a web application running in under 15 minutes, I knew that this was something big.

So many of the modern web application languages available today require assumptions to be made. Configuration settings, typically stored in large and difficult to read XML files, are assumed to be static but RoR makes no such assumptions. Using inspection and reflection, Ruby can change its configuration settings at runtime so that changes made to a database structure are promulgated to the application itself without having to do the reconfigure, recompile and redeploy dance so many J2EE folks have gotten used to. And most important of all, less assumptions equals less fuck ups.

Today is the first day of the rest of my web development life. I had two books waiting for me when I got home and I can hardly wait to crack them open. So after I sign off here I'm off to dive into my new RoR books. Look for more articles here on this subject as I learn about this amazing new framework.