APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

2005/05/04 SSO (Single Sign On)

© May 2005 Tony Lawrence

Most of us have to identify ourselves in many different places nowadays. We may have multiple accounts across the web, or even multiple accounts within one organization. The idea of Single Sign On is that we authenticate ourselves once, and then everywhere else we go knows who we are. How convenient. Why identify yourself over and over again?

Well, I'm the grumpy old man again here. Yes, SSO is convenient. So is having no authentication at all. Convenience always lessens security, and that is why I am no fan of any of this. At least not until there is some absolutely foolproof, non-exploitable method of authentication. Until then, any time you let one authentication serve for multiple resources, you have lessened your security and increased your chances of unauthorized access to those resources.

Microsoft's Passport is a SSO project. So is Shibboleth, Sun's Project Liberty and a bunch of others listed at https://middleware.internet2.edu/webiso/.

Because people are lazy, they'll choose convenience over security every time.And that basic fact is the major source of most of our virus/spam/spyware problems today. There is something to be said for "hard to use", "unfriendly" systems where your typical user can't do anything without help. When no intelligence or intellectual effort is required, security suffers.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> SSO (Single Sign On)


Inexpensive and informative Apple related e-books:

Take Control of Preview

Take Control of iCloud, Fifth Edition

El Capitan: A Take Control Crash Course

Take Control of Numbers

Take Control of IOS 11

More Articles by © Tony Lawrence

Wed May 4 00:33:49 2005: 442   drag

What about situations inside a orginization were you can use a strong authentication system like Kerberos to get SSO, at least for your internal stuff?

Seems to me that using something like that inside a orginization would end up being quite a bit more secure then having to send passwords over the network everytime you want to access a service. Hell with kerberos no passwords are ever sent over the network if it's done optimally.

Plus it would be easier to convince people to use effective passwords since they only would have to enter it once for each computer session.

I am just saying this because I've been playing around with setting up a sort of 'linux domain' at home, for the learning experiance.

I have home folders shared using OpenAFS, have ldap serving up group and user information and it uses TLS encryption with OpenSSL. Ldap uses SASL with GSSAPI to authenticate against users accessing it using kerberos. Nsswitch with ldap support handles stuff like mapping the uid and guid numbers universally and of course MIT kerberos has control over the realm and contains the passwords.

Of course having a single place to store all your passwords online for a bunch of independant online services then that's a bad idea. Passport was always a very bad idea.

Wed May 4 10:26:10 2005: 444   TonyLawrence

I'd say it depends on how big the org is and how important each resource is. If you have a lot of scattered resources, many of which are critical, I think SSO is a bad idea.

Even in my small network, I won't do it. A security breach could cause me to lose one machine, but I'm not going to chance losing everything at once.

Wed May 4 13:08:20 2005: 455   drag

That's interesting. You gave me something to think about for a while.

How I have it setup currently that even if my desktop gets rooted then that wouldn't get the attackers far.. initially. They would not be able to access my home folder at all, even with root access. They'd have to install a keylogger or something tricky like that. Even after then got my user password then that would only let them access my files and services/machines I am athenticated to use. Other users and machines would be isolated. (Of course if they get local access then it simplifies rooting other machines I have access to)

If I had multiple servers that ran services that were athenticated thru kerberos, and everything was setup correctly (big caveat). Then they would only be able to use those services to trick users that are pre-configured with the kdc. They wouldn't be able to obtain passwords of people logging into the server since the passwords are never sent to them.

If a attacker tried to do a DNS spoof and have services redirected to their own machine (not a machine of mine that they rooted) the only thing that would happen then is people's logins would time out. They wouldn't be able to spoof services or get peoples passwords, since the authentication works 2 ways.. Users athenticate are athenticated, but then so are the services. Which is a huge benifit to kerberos (if properly setup, again). It's like ssl stuff online, only that either it works or it doesn't. It's all or nothing. There is no 'press here to ignore'.

OF course the weak link is the machine that actually runs the KDC, or any of the KDC replicates. You can mitigate that a bit by physically seperating the actual authentication server (the part that stores the passwords) and the Ticket granting service onto different machines. But if any of your authintication servers get comprimised... Then your whole operation, all your user files, all your servers, are laid bare to the guy who 0wnz that machine.

So I see it as a trade off. You have a much more secure network.. no passwords are being passed over the networks, the services never need know the actual passwords. The services are authenticated as much as the users, so dns spoofing is much reduced in threat. etc etc. But you end up with a single point of failure.

Of course this is only with a ideally setup kerberos authenticated network. Which I doubt will ever happen.

Hell. Reminds me of JRR Tolken's book 'The Hobbit'. With that dragon that is impervious to all attack, but has that one scale, that one chunk that is missing. And I am sure we all know (or at least can figure out) what happenned there.

Wed May 4 17:16:46 2005: 458   Dave

The problem is, single sign on is an easy sell. Most businesses are not in the business of Tech, they use Tech, its a tool. If you spend to much time messing with your tools, then you do not get the real work done.

Sales people want to spend time selling, not trying to manage a portfolio of passwords.

That being said: Single signon, is very insecure. Once I breach the originator of security, there are almost no checks to verify I'm who I should be. Lets use active dirctory/LDAP server as an example. They use Kerberos I believe to keep the actual server/password conversation encrypted, but lets say I get the admin password. I now have the key to the world, and it can be a very big world. I can browse all servers, and move around with impunity. Worse then that, because its such a big world in many corporations, they do not even have logging turned on because of the performance hit on the systems.

Compare that to a series of unix servers that are say set up in pillars, production, development, testing, etc... If you have a different root password in each pillar/department set of servers, then you've managed to limit or at least slow down the cracker giving you a chance to react as your logs and checks start going off.

10 years ago, I was asked to implement a single signon for unix, novell, and windows desktops. Its was a nightmare to administor, the only thing it really gained for us, was the CIO stopped complaining about forgetting his passwords. :)

ssh and kerberos can supply most of the security items you need to keep yourself resonable safe. Which is the best you can hope for.

The only real safe server, thats 100 percent secure, its filled with concrete and dumped in a deep lake. Then its only secure if nobody knows where it is.

Dave M.

Wed May 4 21:34:16 2005: 462   TonyLawrence

the only thing it really gained for us, was the CIO stopped complaining about forgetting his passwords.

My point exactly : convenience trumps security.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

The idea of "work, then get paid" has been deeply ingrained in our culture by employers who want to limit their risk. Well, I like to limit my risks also. I like to get paid before I do work. (Tony Lawrence)

Linux posts

Troubleshooting posts

This post tagged:


Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode