Previous PDF

swipe to navigate

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.


Enterprise Single Sign-on

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:

  • E-SSO client software is installed on user PCs.
  • Users sign into their PC using a password or other primary credential.
  • A local or network file, database or directory is used to store application login IDs and passwords for each user. This is often referred to as a "password wallet."
  • When a user launches an application, the E-SSO client software automatically fills in the ID and password fields in the login screen with credentials from the aforementioned "wallet."

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.

Web Single Sign-on

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:

  1. CA (formerly Netegrity) SiteMinder.
  2. Oracle (formerly Oblix) COREid.
  3. IBM Tivoli Access Manager (TAM).
  4. RSA (formerly Securant) ClearTrust.

Password Synchronization

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:

  • Users with fewer passwords tend to remember them.
  • Simpler password management means fewer problems and fewer help desk calls.
  • Users with fewer passwords are less likely to write them down.

There are two ways to implement password synchronization:

  • Transparent password synchronization, where native password changes, that already take place on a common system (example: Active Directory) are automatically propagated through the password management system to other systems and applications.
  • Web-based password synchronization, where users change all of their passwords at once, using a web application.

Previous PDF

Comment via LinkedIn