This document lays out what works and, more importantly, what doesn't work well with traditional approaches to enterprise single sign-on. It goes on to describe an alternate approach to reducing the frequency of sign-on prompts presented to users, that does not have any of the problems described here.
This document is primarily concerned with Enterprise Single Sign-on (E-SSO) applications:
Enterprise single sign-on (E-SSO) systems minimize the number of times that a user must type their ID and password to sign into applications.
Most enterprise single sign-on systems work as follows:
The password wallet is often encrypted, normally with a key derived from the user's primary password. Where users sign into their PC with a smart card, a private/public key pair is used to encrypt the wallet. Where other types of credentials, such as proximity badges or biometrics, are used to sign into the PC, wallet encryption is necessarily based on a retrievable password and the overall scheme is insecure.
E-SSO software acts as a surrogate for the user: storing, retrieving and "typing in" the user ID and password on behalf of the user. The user continues to have multiple ID/password pairs, but does not have to type them manually and may not know what they are.
When applications prompt users to change their passwords, E-SSO systems often choose a new, random password and store that in the password wallet. This results in a situation where users no longer know their own application passwords, so are totally reliant on the E-SSO system to sign into applications.
This document does not pertain to Web Single Sign-on (WebSSO) applications, but they are described here for completeness:
A Web access management (WebAM or WebSSO) system is middleware used to move the authentication and authorization of users out of individual web applications, to a shared platform.
A WebAM system intercepts initial contact by the user's web browser to a web application and either verifies that the user had already been authenticated (typically tracking authentication state in a cookie) or redirects the user to an authentication service, where the user may use a password, token, PKI certificate or other method to sign in.
Once a user is authenticated, the WebAM system connects the user to the application and passes identity data to the application, which need not authenticate the user itself. Some applications support direct injection of identities and require no password at all, but other applications require users to connect with a password, in which case the WebAM system must maintain a database of passwords for all users, injecting them on demand.
WebAM systems can also limit user access within applications, for example by filtering what URLs users can access or through closer integration with individual applications, which use a WebAM API to decide whether a user should be allowed to access a given function or not.
WebAM systems normally rely on an LDAP directory to identify and authenticate users.
WebAM systems are mainly designed to work with applications that cannot externalize identification, authentication or authorization using standards-based federation protocols.
Commonly available WebSSO / WebAM products are appropriate to both Intranet (thousands of high-value, high-complexity, low transaction-volume users) and Extranet (millions of low-value, low-complexity, high transaction volume) use.
WebSSO / WebAM products are available from major platform vendors. Most of these were acquired from smaller, specialty software makers:
It should be noted that while the identity management and access governance components of these WebSSO / WebAM products are generally robust solutions for managing a single (LDAP) directory, they are unsuitable to managing complex users with multiple accounts on multiple systems, as they have no concept of multiple target systems or users with unique combinations of accounts.
Vendors that make traditional E-SSO products like to suggest that password synchronization is somehow bad (compromise one password and all are compromised).
An alternate approach to single sign-on, described later in this document, is actually based on password synchronization.
For these two reasons, it makes sense to define password synchronization here:
Password synchronization is any process or technology that helps users to maintain a single password, subject to a single security policy, across multiple systems.
Password synchronization is an effective mechanism for addressing password management problems in medium to large organizations:
There are two ways to implement password synchronization: