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 are designed to minimize the number of times that a user must type their ID and password to sign into multiple applications.
Most enterprise single sign-on systems work as follows:
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.
With an E-SSO system, users sign into their PC with either one or two login ID / password pairs: One set of credentials if the E-SSO captures the user's password from the initial PC login screen, or two ID/password pairs if the user must first log into the PC (e.g., Windows login) and subsequently into the E-SSO client software.
Some E-SSO systems support use of authentication technologies other than passwords to sign into the PC and retrieve the user's application passwords. This may include smart cards, authentication tokens or biometric samples.
Application login IDs and passwords may be stored on a smart card, rather than on the user's PC or on the network.
This document does not pertain to Web Single Sign-on (WebSSO) applications, but they are described here for completeness:
A Web access management (WebAM) / Web single sign-on (WebSSO) system is middleware used to manage authentication and authorization of users accessing one or more web-enabled applications. Is supports single sign-on across systems and applications which do not natively support federation.
A WebSSO 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 else redirects the user to an authentication page, where the user may use a password, token, PKI certificate or other method to authenticate himself.
Once a user is authenticated, the WebAM component of the system controls the user's access to application functions and data. This is done either by filtering what content the user can access (e.g., URL filtering) and by exposing an API that the application can use to make run-time decisions about whether to display certain forms, fields or data elements to the user.
WebSSO / WebAM products typically use an LDAP directory as a back-end repository, to identify all users. They often come tightly integrated with an "identity management and access governance" application, which enables delegated and in some cases self-service administration of the contents of that single directory.
Federation is almost always preferable to WebSSO. 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 on an enterprise network:
There are two ways to implement password synchronization:
The core element in every traditional E-SSO product is the concept of a credential database. This may be encoded in different ways and stored on various media but fundamentally it is a set of login ID / password pairs that the E-SSO application will type on behalf of the user when each application prompts for login verification. This data must be available for every user.
Over time, a traditional E-SSO system will respond to applications expiring passwords by choosing new, random password values, allowing the application to change passwords and storing the random password value for future reference.
With this process in place, over time users lose knowledge of their own passwords and become dependent on the E-SSO system to sign into their applications. This means that users cannot access their applications from devices that are not equipped with the E-SSO software, such as smart phones or even their home PCs.
Building and maintaining a database of every login ID and every password on every application can be both costly and time consuming.
Login IDs and passwords stored in a traditional E-SSO system are typically encrypted using a key derived from the user's primary network password. When users forget their primary password, they lose this key and can no longer decrypt their application passwords. As a result, password problems may be less frequent with E-SSO, but resolving them is more complicated, time consuming and expensive.
In the event that the password database in a traditional E-SSO system is compromised, every user ID and every password would be exposed.
If the password database suffers an outage, every user would be locked out of every application.
Some E-SSO vendors try to turn some subset of these problems into competitive advantages, or as a justification for cross-selling other products:
These operational problems are serious. It is Hitachi ID Systems's opinion that these problems prevent most large enterprises from completing large-scale E-SSO deployments. Instead, pilots and department-scale deployments, which work reasonably well, hit these roadblocks when trying to scale up, and project scope is subsequently curtailed.
Many E-SSO vendors claim that E-SSO is more secure than password synchronization. They reason as follows:
These arguments are very weak, however:
As a result, a compromise of any one security database is quite unlikely. If such a compromise were as easy as claimed, then every corporate network would be under constant and successful attack, which is clearly not the case.
Current security best practices generally recommend setting the intruder lockout counter high (on the order of 50 -- 100 failed attempts) anyways. A low count is no substitute for strong passwords and if passwords are strong, there is no harm in setting the counter high, since the password will not be guessed in anything short of billions of guesses.
In other words, the only difference between password synchronization and E-SSO in relation to the single password argument is which password must be compromised before all are compromised -- the primary password or any of them. This is not much of an advantage for E-SSO.
Having debunked the security argument, the remaining advantage of E-SSO systems is that they improve the user experience, by reducing the number of times that a user, in a given day, must type his ID and password.
The problem with E-SSO is basically the credential database -- it is expensive to acquire and maintain, is an attractive target for attackers and prevents users from accessing applications from devices that are not equipped with the E-SSO client software.
Login Manager automatically fills in application login IDs and passwords on behalf of users, streamlining the application sign-on process for users.
Login Manager works as follows:
The net impact of Login Manager is that login prompts for applications with well-known IDs and passwords that authenticate to AD or are synchronized with AD are automatically filled in. This is done without:
Login Manager is installed as a simple, self-contained MSI package. It does not require a schema extension to Active Directory.
The reduced sign-on process used by Login Manager has several advantages over traditional E-SSO techniques:
These advantages significantly reduce the cost and risk associated with deploying and managing Login Manager.
In order to achieve its benefits of low cost and high availability, Login Manager makes three important assumptions:
It may either be a single ID (i.e., the user's network login), or a short list.
Where users have different login IDs on different systems, Hitachi ID Password Manager can generate login ID aliases using a combination of automation and self-service enrollment and can write this data to the user's profile in Active Directory or eDirectory. Login Manager can retrieve this list of login IDs at login time.
Since Login Manager does not store a user's passwords anywhere, it depends on a user's application passwords being the same as the user's primary network password.
Since Login Manager acquires a user's primary network password from the Windows login process, that process must itself use a password.
Combining Login Manager with other authentication technologies, such as smart cards or one time password tokens, may require extra integration effort, so that Login Manager can retrieve the user's synchronized password from a different source.