< Back to Article List
Understanding Single Sign-on
By: Laura Taylor
May 28, 2002
For a large enterprise, as the number of passwords each user is required to maintain increases, so do the support calls. With each of these calls having an associated operational cost of $32 (according to Gartner Group), and the increasing number of applications in use, businesses cannot afford the productivity lost through continuous password resets. Single sign-on has evolved as a cost savings solution to minimize support calls, and at the same time simplify the administrative process of authentication and authorization.
Two Types of Single Sign-on
Web Single Sign-on
SSL is CPU intensive and, for the most part, a server can support only a limited number of SSL handshakes. In some cases, SSL accelerators can resolve this performance problem. However, SSL cannot create a user experience, where on a front-end portal, the user puts in one password, and all the other applications on the backend of the portal receive authentication information about that user. A properly implemented single sign-on solution will write the front-end authentication through to a central management console on the backend, and share this information between applications for the extent of the user session. Also, SSL only can work between two endpoints, so if a transaction involves three parties such as a customer, a merchant, and a card issuer, you cannot use SSL.
Legacy Single Sign-on
Single Sign-on and Password Synchronization are Two Different Things
For true single sign-on products that offer advanced and sophisticated capabilities, a user can actually have different passwords for every application. The single sign-on server stores these passwords in a protected database, and makes them available to the user upon login. When the user attempts to access an application, the single sign-on product retrieves the password from the database, and executes the login for the user transparently. So in this type of scenario, you actually have multiple applications, with multiple passwords.
True single sign-in is far more secure than password synchronization, and it is unfortunate that many IT decision makers have not come to make this distinction. When all applications have the same password, if a user's password is compromised by say a hacker, the hacker can then access all the other application in the enterprise. If a password synchronization system becomes compromised, it can create a security problem of catastrophic proportions. Password synchronization might have been the best thing to solve the apparent single sign-on problem at one time, but now there are better solutions that solve the problem with a much higher degree of security.
So Who are the Players?
Features to Look For
The importance of these features to your organization depends on how you want to use your single sign-on platform today, and how you might want to use your single sign-on platform down the road, perhaps a year from now. For example if you have both UNIX and NT domains, cross-domain authentication will be of paramount importance. If you are not going to be using your single sign-on solution for a customer, supply-chain, or partner portal, than personalization might have little, if any, importance.
A feature that is particularly important for just about all large-scale implementations is the ease-of-use of the central management console. If you are supporting a vast array of applications, the central management console is what brings the administration altogether. The administrator should be sure to understand what sort of process is required to update or change a rule or role. Does this change take place instantaneously? A very good test on determining administrator ease-of-use would be to test out adding, deleting, and changing a user's role on each product in consideration. Also, how hard or easy is it to setup rules?
Next, ask about the logging features. Can the logs be filtered on various criteria? You might want to find out for example, which IP addresses are continually trying to get in, but are not being allowed access. This could be useful to know in case you have a computer breach down the road, maybe from some other part of your network that is not connected to the single sign-on infrastructure. Things that you will want the log files to filter on will be domains, IP addresses, or even user names. Of course if these filters don't exist, you can resort to writing your own filters using grep and awk shell-scripts. Don't forget to ask if the log files roll-over and archive so you don't have to worry about your file systems filling up.
Installing and administering most single sign-on products on UNIX platforms don't require much advanced knowledge of UNIX itself. Most of the products are GUI driven, and their installation, configuration, and management are based on point, click, and return-key sequences. The part of the implementation that takes some understanding is assigning the rules and the roles.
Single Sign-on is Worth the Effort
|Copyright 1997-2015 Relevant Technologies. All rights reserved | Legal and Privacy | Sitemap
Email: firstname.lastname@example.org | Tel: 240.786.4858 | Fax: 855.451.5466 | 8160 Maple Lawn Blvd, Suite 200, Fulton, MD 20759