Database Reference
In-Depth Information
C H A P T E R 8
Single Sign-On
Single sign-on (SSO) is a relatively simple concept. Did you log in when you turned on your computer,
before you were able to start working? If so, then we ought to be able to find out who you logged in as
and assume that your identity is the same when you use our applications.
Part of the mystery here revolves around assurance and trust. Can I trust that initial log in to be
secure enough so that only the actual user can authenticate as himself? Can I be sure that no one else
has that username and password, and that no one can pretend to be that user (spoof the user)? This
assurance comes not only from the power of the encryption and the strength of the password storage
protection, but also from the computer security code of conduct: frequency of password change,
password composition and strength rules, screen-lock rules, rules against password sharing and posting,
education about malware and viruses, and social engineering. This assurance also comes from network
access control (NAC). Do we assure that each client computer has the latest updates and anti-virus
software? Do we assure that client computers are correctly configured with security options, like our
password-protected screen lock? Do we protect mobile computers with hard disk encryption, firewall
software, and virtual private network (VPN) when they communicate with our company over public
networks? And do we use NAC to do all this
before
we allow those computers to connect to our corporate
network?
If I am sure of all these things, and anything else that is required to combat a computer security
threat, then I can trust the original log in to be good enough for any further identity requirements. There
is a large foundation that we require before we can continue building our application security with SSO.
Another Layer of Authentication?
We could always add another authentication in our application—a chance for the user to reenter the
username and password (possibly a different password), but beyond frustrating the user, have we
improved on security? (In the next chapter, we will try to improve on security with 2-Factor
Authentication.)
I'm not saying that extra authentications are a bad thing. Sometimes you do not have the trust and
assurances I listed previously, so SSO is not valid. The problems come when you have ten or tens of
passwords. At that point, two things happen: your authentication support systems get heavily taxed
because of lost or forgotten passwords and innumerable password resets, and your organization's (and
personal) security decreases. Can it be true that security decreases with increased quantity of
passwords? Yes, because now you have placed users in the position where they have too many
passwords, changing too often to remember—they must be written down.
Perhaps your users are savvy enough to keep a list of all the places they have passwords, and when
they change them one place, they change them all places. I'm not sure you can count on that, even in a
computing organization with less than 10 people. And there are always exceptions—passwords that
change more frequently and passwords that have different composition rules.
