Web Development

SSO Sucks

Single Sign-on sucks. Well the idea doesn’t suck, but in practise, it sucks. It’s one of those buzzwords that bosses, sales guys and business guys love to throw around. I’m pretty sure this guy ALWAYS talks about SSO:


Ok maybe SSO doesn’t suck THAT much. But it ALWAYS sucks A LOT. Here’s my gripe: SSO is really complicated. “Business guys” throw it around cause it’s a cool sounding three letter word. But the concept is difficult. The thing is, you aren’t SUPPOSED to be able to view content without supplying your credentials. So to all of a sudden just expect to view sensitive information without supplying your credentials directly to that provider – is kind of a big ask.

You know what’s funny though? If you’ve ever actually investigated SSO solutions, they’re almost all hacks. It’s never pretty. It’s never clean & elegant. It’s ugly, hacky, and usually problematic. When I first properly heard about the concept, when my boss was asking to basically “SSO” into everything, my first thought was “this doesn’t sound right”. I couldn’t comprehend how it could be done elegantly. And lo and behold as I started to investigate the solutions, as I expected, its’ UGLY! Way before I implemented any actual existing packages or toolkits or services, I wrote my own attempt at SSO for a job a long while back, it was really hacky & nasty with forms, scraping, session & cookie wrenching (technical terminology), even iframes (shudder), you name it – it had it. The funny thing is, the first third party SSO service I ever worked with (we had to integrate with the service as a client) turned out to be almost exactly the same using all of those techniques! A nasty hack. Since then I’ve implemented at least 3 more entirely separate solutions, but they basically do the same thing and are all basically variants on the same kind of hack.

I don’t want to get into the technical details, but the key thing is this. You can’t PUSH someone to another site and have them authenticated. You just can’t do it, it doesn’t work like that. It’s more of a combination of pushing, pulling, services & hacking. I’m pretty sure most bosses just think “no problem, just configure it so we can CRAM our users to google or amazon or ebay already securely authenticated”. No problem.

Take a look at SAML for example. Oh man. SAML sucks. I figure it is like SOAP is to the web. Take a concept, add some web services, jam about 10 billion tonnes of XML around it, have about 20 complicated requests & responses and there you have it. Then you get business guys discovering the word and they’re like “SSO difficult? Not at all! Just use SAML!” “Oh really? is that what I need to do? How about you cram your own legs into your neck joint and twist it forward-ways.

On that note, the package SimpleSAMLPhp – named that way obviously to differentiate it from the extremely complicated standard/data format, is not that simple!

Anyway, would be keen to hear from other peoples experiences.

2 thoughts on “SSO Sucks

  1. Too funny. I found this article while searching for “simplesamlphp” and “Internet Explorer” because of a MSIE-only problem with our SAML server. SSO has been a struggle for me lately because our apps folks have been outsourcing a bunch of web-apps to 3rd parties which then want to use SAML to authenticate users. Then the apps team says “But this is sensitive data so if they log out of the web app, it should require them to enter a password again to get back in”.

    Ummm… that sorta flys in the face of what SSO is about. Once you’re auth’d in SSO, you’re auth’d for ALL SSO apps, until the auth times out or you close your browser. To which the apps guy says “Well, we should set the SAML auth timeout to 30 minutes then”… ARGH! Why bother with SSO then?

    Ok, having gotten that rant off my chest… 🙂 At least with simplesamlphp I don’t have to be rich as croesus to setup SAML, don’t have recurring license fees up the ying-yang and when some silly app requires the data to be munged in some format the answer to whether or not our SAML server can do it is never no but generally “yeah, probably, but not in the next 60 seconds.”

Leave a Reply

Your email address will not be published. Required fields are marked *