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.

This article was first published on Intranet Journal, an site.