It takes more than a stamp and a carrier to get a letter from the mailbox to its destination; an army of U.S. Postal Service employees collect, sort, process and deliver more than 600 million pieces of mail on a daily basis.
To move the mail across the network of 37,000 locations, Postal Service workers must access mail processing systems, tracking and distribution software, scheduling and financial recordkeeping databases and the usual array of office applications. The average user has 10 unique identities, higher than the six-to-eight average of most enterprises. Stretch that across 300,000 regular computer users and the dizzying array of applications they touch every day, and you've got a lot of pain, says Bob Otto, the Postal Service's CTO.
"If users can't remember their passwords, they'll write them on sticky notes and post them on their monitors, or call our help desk, which costs us money and lost productivity," says Otto. "We wanted to simplify."
Otto's solution: enterprise single sign-on (eSSO), the dream of network architects since the advent of decentralized, heterogeneous client-server networks. eSSO, not to be confused with its cousins, Web SSO and federated SSO, is more than just the simplification of access through scripts automating Windows logons (see "Different Flavors of SSO"), and it goes beyond the tricky process of password synchronization. Users are able to access every authorized application with a single user name/password combination, improving the user experience, decreasing help desk calls and enhancing security by getting rid of CRT sunflowers.
Contemporary products aren't your father's SSO, though. Gone are the days when eSSO meant you had to rearchitect your networks and write APIs for every application. Nowadays, eSSO solutions are easier to implement and far more scalable, thanks to maturing technology, persistent network connections and the use of centralized ID management directories. Acting as middleware between applications' access control and centralized identity management systems, eSSO can transparently negotiate logins for numerous applications.
Otto settled on Passlogix's v-GO SSO for the Postal Service's sprawling nationwide infrastructure. v-GO is already simplifying the logon process for more than 165,000 of the Postal Service's computer users; every month, 1,500 more users are being enrolled. The product manages access to more than 1,000 internal applications and 6,000 external, Web-based applications.
"This is probably one of the most reliable pieces of software that worked out of the box," says Otto. "It's saving us millions and helping us with the ease-of-use and security issues we used to have."
As enthusiastic as Otto is about eSSO, he admits that it's not a final solution and that it's not "true SSO." Most eSSO products, including v-GO, are more like password vaults, using stored credentials to simulate an SSO experience. Otto describes eSSO as a "bridge to tomorrow," when legacy applications will be replaced by software natively capable of true SSO.
But as centralized management tools and multifactor authentication mature, the question is whether eSSO is worth the investment today and for the future.
Leaning on the directory
Otto wanted no half measures. The eSSO system he chose would have to natively support all of the applications on his network and scale to support 1 million users. The capacity would allow ample room for growth to accommodate non-computer-using employees, partners and suppliers.
Watch a presentation on the USPS giving SSO its stamp of approval by Wayne Grimes, USPS Service Manager of Customer Care Operations & Information Technology at Information Security Decisions, Spring 2005.
Previously, such an implementation was next to impossible. Writing custom APIs and integrating legacy apps across a network of thousands of sites and hundreds of thousands of users would take years and cost millions (neither Passlogix nor the Postal Service would disclose the cost of the v-GO deployment).
But a lot has changed since the first eSSO implementations of the early 1990s. The emergence of persistent high-speed networks, as well as centralized and distributed directories, gives eSSO applications the tools for large deployments.
The Postal Service's migration from Windows 9x/Novell NetWare architecture to Microsoft's Active Directory laid the foundation for its eSSO deployment. AD, like other directory services, provides enterprises with a centralized store of user and device information, which they can leverage to manage credentials, push patches and software upgrades, and maintain user profiles.
Most eSSO solutions harness the power of the centralized directory, whether it's AD, Novell's eDirectory or Network Directory Service, or LDAP. eSSO acts as middleware in the access control and authentication routine, replacing the native network logon. Once the user authenticates to the network, the eSSO software intercepts subsequent logon calls to applications, devices and Web sites and verifies the users' credentials stored in the directory, transparently asserting their permissions and credentials to the requesting application.
eSSO doesn't replace provisioning tools or access control systems. Rather, it complements these systems, using their accounts, permissions and policies to automate the access and authentication routine.
In a typical Windows environment, the user logs on to the network (or his PC if it's disconnected) with the standard Windows logon interface, providing a user name and password. The credentials are processed through AD, which issues either a Kerberos ticket or security identifier. (This is key -- it will be the validating element for all subsequent user authentication requests.) Once successfully logged onto the network, the user can transparently pass between authorized applications. Each time the eSSO recognizes an access control interface, it checks with Windows (e.g., the user's Kerberos ticket or security identifier) to make sure he's properly authenticated to the network, then checks AD or an optional local cache to see if his credentials authorize access to the requesting application. The eSSO will retrieve the stored user name and passwords from the directory and transparently pass them to the application. Unless specified by policy, the user doesn't have to do a thing.
When the user's machine is disconnected from the network, credentials stored on the eSSO client directory allow transparent access to local applications.
All stored credentials-on the client and in the directory-are encrypted, as well as the communications between the eSSO middleware, the directory stores and the clients.
Enterprises can achieve much of the same password simplification through AD and Novell's directories, but they don't achieve the same functionality and control as COTS eSSO solutions. Such implementations suffer from the same problems as previous SSO efforts-high integration costs and low scalability. For less complex infrastructures this may be an option, but it would take a lot more work to implement for large, heterogeneous networks replete with legacy apps.
Surprise! eSSO isn't about security. It's about easing user experience and enabling simplified sign-on.
Users can enroll their own credentials for unsupported applications, such as restricted websites and third-party apps. For instance, when users are prompted with a logon interface for the first time, Passlogix's v-GO will ask them if they'd like to have the credentials stored as part of their eSSO profile.
"If users go into another application they use for their own purposes, it will help them manage their Web pages as well," says Wayne Grimes, the Postal Service's manager of customer care operations. "I don't have to make any changes to that application at all; it will sync and manage their passwords for these different applications through Active Directory."
Glossary: Different flavors of SSO
There are different forms of SSO. Each overlaps, but they still have dramatically different capabilities and limitations.
Enterprise SSO: This typically refers to applications that manage authentication to internal network applications and resources, as well as Web-based applications. Vendors offering eSSO solutions include
Citrix Systems, Computer Associates, IBM Tivoli, Microsoft, Imprivata, Novell, Passlogix, Protocom Development Systems and RSA Security.
Web SSO: These are applications that provide SSO authentication and access to Web applications, extranets and portals. They typically can't extend into the internal network. Vendors offering Web SSO solutions include Computer Associates, Netegrity* and IBM Tivoli.
Federated SSO: Similar to Web SSO, it uses SOAP and SAML to leverage federated directories to assert user credentials and privileges across different domains. Vendor offerings include Computer Associates, IBM Tivoli, Netegrity, Oblix and RSA Security.
Password Synchronization: Often confused with SSO, synchronization harmonizes passwords for different applications under a uniform password. Vendor offerings include Courion, IBM Tivoli, M-Tech Information Technologies and Novell.
*Netegrity was acquired by Computer Associates last month.
Further enhancing the user experience is the removal of the need to manually change stored passwords. Many eSSO solutions will automatically generate passwords in accordance with policy for various supported applications. The user can continue to apply the same front-end password without interruption.
What the Postal Service discovered, though, is ROI through reduced password-related help desk calls. Such calls were costing the Postal Service $7.5 million per year.
"The nice thing about using this new technology is that, even as it grows and we're spending money, we're saving even more," Otto says.
Remembering multiple user name/password combinations is difficult, even for those with photographic memories. Stroll through any enterprise's cubicle maze, and you'll find at least one workstation monitor ringed with sticky notes with passwords scribbled on them.
Otto believed that reducing the number of passwords users were required to remember would improve security.
"Surprise! eSSO isn't about security."
But that's just the surface benefit. Behind the scenes, eSSO solutions help enforce strong password policies. Many SSO products will automatically select a password in accordance with enterprise security policies when it expires. If the policy requires that the password to financial records be changed every 30 days and must be a 16-digit mixed alphanumeric, the eSSO will automatically generate the new password and store it in the directory.
For applications that aren't governed by internal security policies, such as third-party Web-based applications, the eSSO software will intercept the request for a password change and perform the same process.
This also creates a single point of failure: Because the eSSO password unlocks the vault to all the stored passwords, a single compromise of the user's primary password could lead to a major security breach. Enterprises adopting or exploring eSSO need to recognize this potential risk and, in some cases, adjust for it through multifactor authentication. Many SSO solutions are designed to leverage tokens, smart cards, certificates and biometrics.
"You really do increase the risk if you don't use some form of strong user authentication on the front end," says Herb Mehlhorn, senior product manager at RSA Security.
In some cases, this means enabling eSSO for routine applications but requiring separate logins for higher-level applications and resources.
While eSSO simplifies the login process, it doesn't work in reverse. Users are still required to manually initiate the logout process from applications. Some applications will time out a session, but this and user error could leave accounts exposed to session hijacking. Health care organizations, which are subject to HIPAA requirements, are using RFID tags that automatically log users into and out of terminals depending on their proximity to the reader.
Do we need SSO?
Here's the big question: If directory services continue to evolve and applications become more standardized for passwords and other authentication mechanisms, why do we need SSO?
Eventually, as legacy apps are replaced by Web-based applications, enterprises will be able to leverage applications' native authentication to enable true SSO without the middleware.
In time, eSSO will be subsumed by its cousins, Web SSO and federated SSO, and will be able to transparently assert user credentials across domains through federated directories and to third-party Web-based and portal applications.
The eSSO applications of today are, as the Postal Ser-vice's Otto describes, bridges to the future. They improve user experience and security in the mixed environments of contemporary systems and legacy applications.
"This is a staging tool that shows us how we ought to build and standardize applications to use AD for all security in the future," Otto says. "What we do with legacy stuff is faking it out. This is the bridge from the old to the new. Maybe by 2015, we have the entire Postal Service on one user ID and password."
About the author:
Lawrence M. Walsh is executive editor of Information Security magazine.