Writing

Software, technology, sysadmin war stories, and more. Feed
Tuesday, January 24, 2012

Hitching my authentication to the corporate mail server

I used to get all sorts of weird internal requests back in the days when I worked either tech support or later on the "meta" tech support team. One time, it was decided that we were going to do an "employee of the quarter" thing, complete with semi-finals and a final competition. Somehow, this wound up finding its way to me, and they wanted me to create an internal web site to host it.

It wasn't a bad choice since I knew how to do it and would make sure it worked, but it was kind of strange. It wound up being this odd hybrid of static HTML and only a wee bit of CSS, for those were the days when CSS was poorly supported as a whole. All dynamic content happened with an awful server-parsed (shtml) hack to "#include virtual" my CGI programs at strategic points in those pages.

There was only one part which was even remotely interesting about this. I wanted to authenticate people so they could vote once. It wasn't really anonymous voting, since I tracked who voted and who they voted for, but I was the only one with access to that database and I wasn't telling. Years of doing the sysadmin thing had taught me that snooping is poor form and evil and besides... it's boring!

My problem was authenticating these users without setting up yet another password regime or trying to get the corporate IT folks to hand me "SSO" auth access. I came up with something which seemed simple in retrospect but still doesn't seem to be used too much today.

I mailed them a link with a unique identifier "baked in". That link set a cookie and redirected them back to the top page, which would then behave appropriately. Anyone with that cookie must have been that particular user.

That was the whole scheme. It was only as secure as your mailbox, but that's all it needed to be. If you were silly enough to forward your auth-cookie-link mail to someone else, then sure, they could log in and vote as you, assuming you hadn't already voted at that point. Then again, who would purposely forward such a thing to another person?

It worked marvelously. All of my users managed to get through the process without generating any support queries of me. I interpreted that as having successfully created something that they could figure out on their own. Victory!

Better still, these cookies were persistent, and I kept that particular table around, so when the VP came back around 6 months later to do it again, it was even easier. People who hadn't lost their cookie in the meantime were still "logged in" and could go straight in and vote without doing the mail step again.

Much later, something came up where we needed to identify who was using a particular internal web page. I wound up adding a tiny (1x1) invisible IMG on that page which came from my voting server. Any time someone went to the page in question, they'd also reach out to my voting machine and send their voting cookie. That could then be cross-referenced back to their username, and there was our answer.

These are the types of rogue internal hack jobs you get when there is no chance of getting a reasonable authentication scheme working internally. If all you get from the gatekeepers of corporate IT is the run-around, odds are you are going to treat them as damage and route around them. A few enlightened companies understand this. Others definitely do not.