Grandpa always said, “Never try anything new. Wait and see if it kills someone first”. Recently, I’ve been involved in bringing several Single Sign On projects to fruition, and his words have been hovering in the back on my mind constantly. Part of me says, “It’s a bad idea to have just one username and password accessing everything”. If a hacker attack occurs, the intruder gets hold of their stuff, they’ve got access to everything. But the other part looks at it and says, “The users are going to love this”. It’s a classic situation of being stupid if you do, and stupid if don’t. So, what do you do?
What is Single Sign On?
When you first look at Single Sign On (SSO) from the perspective of someone up on security, but not understanding the ins and outs of it, SSO looks like enterprise level suicide. The very name, Single Sign-On ?onjures up images of using one set of credentials for everything, but the bottom line is it’s designed to make life easier on your users, and not compromise security. What you’re doing is taking advantage of something called SAML (Security Assertion Markup Language, no less). This is an XML-based, open source data format that allows us to exchange authentication and authorization data between different applications or parties. It actually hardens things a bit by adding another layer in there so to speak by leveraging the users AD or LDAP information.
So we’ve enhanced the security by tying how they affect rights already granted in AD. In most cases if there’s a separate username/password associated with an application, that’s entered once, and the SSO app gives us access. Sounds a little scary, but keep in mind typical AD lockouts still work, and we have the added benefit that if the account is compromised, most SSO software come with some really powerful reporting features. So we can detect compromised accounts and accessed data.
Questions to ask before committing to Single Sign On
I’m going to play my own Devil’s advocate here and ask the question that’s on everyone’s mind. Just how secure is it really?
Well, like the Devil, I’m going to string you along on the answer and say, we’ll be looking at that one in the weeks to come. Right now, let’s assume that you want to go out and do some Single Sign On in your organization. If you want SSO in your organization, here are a couple of things to think about.
First on the list, are we talking about something new, or something that we’re upgrading? Often times it’s a new SSO product replacing an old. Right there, you need to start thinking of training and communications. Communications – so users know what’s going on, training (even if all it is an online video) – on how to use the new product.
What are we trying to do with it? Are we trying to centralize access? Trying to improve on security by improving authorization? Or how about just plain old auditing? Maybe we’re trying to accomplish all three. Bottom line is it sure helps to do a successful project when you know what to expect at the end of it all.
Deciding what applications we want to provide access to early on is very important. Most applications will play nicely with a SSO, but others won’t. The “others” just might make life really difficult for you, and involve third parties and more than a little creativity to make them work. So expect that.
Who’s’ going to take care of it? Someone has to be responsible for the system, and it may involve several people at different levels of the company to handle it. For example, in a recent SSO project, I was responsible for setting it up on the servers, helping to manage the project, and get the initial applications and seeding of users done. But it was determined early on, that in the future, new users would be added by the Tier 1 folks. So we had to get them and at least give them training up to that point. Applications however, as well as care and feeding of the servers (not to mention future upgrades and DR) would rest firmly in my hands.
Probably the single most important piece we need to look out is if the SSO we buy continues to grow and evolve as the company grows and evolves.
And as they used to say way back in the 60s, don’t touch the dial.
 of ENG [Free Guide] short-384x406.jpg)
