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
There are two main types of single sign-on architecture types - Web-based and non Web-based. For the most part, the various enterprise products available can be segmented into one of these two categories. Today, non-Web-based applications are sometimes referred to as legacy applications, and therefore, the associated single sign-on products that they interoperate with are referred to as legacy single sign-on products. To help you understand what features are important in helping you selecting an implementing a single sign-on product, I'll take a deeper look at these two single sign-on segments.

Web Single Sign-on
The Web is made up of portals which act as gateways to many layers of web sites. Some portals have a unique focus, while others try to be all things to all people. A portal is often the front-end to a lot of different enterprise applications that converge in one Web based user interface creating an organizational single point of presence. When the Web first evolved, Secure Sockets Layer (SSL) was sufficient for passing encrypted passwords via a browser because Web security was based on protecting URLs, not applications. As applications and databases started being attached to the backend of URLs, it became clear that SSL had limitations.

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
Legacy single sign-on products conceptually use the same authentication and authorization architecture structure as Web single sign-on, except a portal is not part of the front-end picture. Legacy single sign-on enables smooth navigation of the various applications on an intranet through one authentication session. Many legacy single sign-on products also offer smart card, PKI, and biometric support. It is worth noting that some industry analysts refer to legacy single sign-on as employee single sign-on.

Single Sign-on and Password Synchronization are Two Different Things
Many people assume that single sign-on means all applications use the same password, however, this is not necessarily true. Users are justified in their confusion though, since the very verbiage "single sign-on" implies that this could be the case. An older, and less sophisticated way, of giving the allusion of single sign-on has been through password synchronization. What a password synchronization system does is distribute and synchronize a main password to other systems. This gives the apparent user experience of single sign-on, but it is not true single sign-on.

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?
Some of the big players in Web based single sign-on are Entrust, Evidian, Netegrity, and RSA Security. All three of these products can be run on UNIX platforms, and offer rules-based capabilities, roles-based capabilities, and LDAP compliancy. Using a rules-based approach is considered more scalable and flexible than using roles because rules can be applied to not just people, but to networks, domains, and IP addresses. Using roles requires more administrative overhead, e.g., when a user's role changes, say, moving to another department, it requires file edits and administrative changes. To be a market leader today, a single sign-on portal product needs to support both rules and roles.

Features to Look For
When researching single sign-on products for your enterprise, here are some features that you'll want to look for, and ask the vendors about.

• URL Mapping hides URLs that you are not suppose to have access to.
• Personalization provides customized user specified features.
• Smart Card supports allows authentication via smart cards.
• Transparent Implementation means that client-side software is not required.
• Encryption algorithms offer advanced security. Ask which ones are supported.
• Digital IDs or Signatures mean that electronic signing capabilities exist.
• Client Platforms indicate which user operating systems can authenticate.
• Central Management indicates administration of many servers from one console.
• Cross-Domain Authentication lets you authenticate multiple domain architectures.
• X.509 allows for support of digital certificates.
• Logging indicates the type of account auditing features available for review.

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
There are clearly benefits to be gained from implementing single sign-on systems. Though people equate the terminology "single sign-on" to security, what you are really getting with these implementations are much more than that. If you're looking to reduce your support calls and expenses, and simplify the authentication process for your users, single sign-on systems offer clear benefits to your organizations. The ability to reduce operational costs, create an improved user experience, and provide advanced security to your systems makes single sign-on well worth the effort.