Still waiting for single sign-on? Don't hold your breath. Today's single sign-on services still rely on password caching and some sort of screen-scraping or scripting interfaces in order to be automatically entered. To be truly effective, a single sign-on system needs to support a token-based authentication mechanism that relies on an enterprise directory service for ACLs (access-control lists). In fact, both essential functions of a single sign-on system are still missing: user authentication services are far from being standardized, and there's no unified enterprise directory to define and store ACLs.

Designed to make user administration across multiple servers easier, NOS directories do include authentication services. For instance, Novell's NDS includes a proprietary RSA-based authentication system; Microsoft Corp.'s Windows 4.0's NT Domain provides a challenge-response authentication mechanism; Lotus Notes includes a public-key client authentication service; and Netscape Communications' SuiteSpot relies on simple LDAP authentication (user name and password BINDs). In addition, Microsoft's Active Directory is built on a Kerberos V5 authentication system (like DCE).

However, to implement a token-based single sign-on system effectively, all network services need to share not only a common directory service, but also a common authentication system. In this case, a user receives a digital token when he or she first logs in. All subsequent authentication challenges are automatically satisfied behind the scenes. To date, the most likely scenario involves the widespread support for X.509 PKI, where network services are authenticated based on certificate authentication similar to that in certificate-authenticated Web services.