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.

1. Overcoming Operational Challenges with
Traditional Approaches to
Enterprise Single Sign-On
© 2014 Hitachi ID Systems, Inc. All rights reserved.

2. Contents
1 Introduction 1
2 Definitions 1
2.1 Enterprise Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Web Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Password Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Operational Problems with Traditional E-SSO 3
4 Is E-SSO More Secure than Password Synchronization? 5
5 Hitachi ID Login Manager: A New Approach to E-SSO 6
i

3. Overcoming Operational Challenges with Traditional E-SSO
1 Introduction
This document lays out what works and, more importantly, what doesn’t work well with traditional ap-
proaches to enterprise single sign-on. It goes on to describe an alternate approach to reducing the fre-
quency of sign-on prompts presented to users, that does not have any of the problems described here.
2 Definitions
2.1 Enterprise Single Sign-on
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 client software is installed on every user workstation.
• Users sign into their workstation, either as they did before or through a new user interface presented
by the E-SSO client software.
• A local file, a network-attached database or a user directory stores each user’s ID and password, for
each system and application to which that user has access.
• When a user launches an application on their workstation, the E-SSO client software automatically
populates the ID and password fields in that application’s login screen with data from the aforemen-
tioned credential storage.
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 workstation 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 workstation login screen, or
two ID/password pairs if the user must first log into the workstation (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
workstation 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 workstation
or on the network.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

4. Overcoming Operational Challenges with Traditional E-SSO
2.2 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) / 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:
1. CA (formerly Netegrity) SiteMinder.
2. Oracle (formerly Oblix) COREid.
3. IBM Tivoli Access Manager (TAM).
4. RSA (formerly Securant) ClearTrust.
It should be noted that while the identity management and access governance components of these Web-
SSO / 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.
2.3 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.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 2

5. Overcoming Operational Challenges with Traditional E-SSO
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:
• Users with synchronized passwords tend to remember their passwords.
• Simpler password management means that users make significantly fewer password-related calls to
the help desk.
• Users with just one or two passwords are much less likely to write down their passwords.
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 are asked to change all of their passwords at
once, using a web application, instead of continuing to use native tools to change passwords.
3 Operational Problems with Traditional E-SSO
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.
Previous approaches to enterprise single sign-on systems had problems, all related to the password database
where application login IDs and passwords are kept:
• Remote Access and Mobile Devices:
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.
• Cost to Deploy:
Building and maintaining a database of every login ID and every password on every application can
be both costly and time consuming.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 3

6. Overcoming Operational Challenges with Traditional E-SSO
• Cost to Reset Passwords:
Login IDs and passwords stored in a traditional E-SSO system are typically encrypted using a key de-
rived 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.
• Security and Availability:
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:
1. Some vendors create a mechanism for users to display their own plaintext passwords, when accessing
applications from non-traditional devices. This is, of course, insecure.
2. Citrix uses the remote-availability problem to encourage customers to migrate their users to Citrix
Presentation Manager. If users access every application by remote control, and the terminal services
servers are equipped with SSO, then the problem goes away (and Citrix sells more server licenses).
3. Most vendors offer some back door, to bypass the credential encryption system with some privileged
credential and so to address the problem of expensive password resets. This can create security
weaknesses and/or administration headaches.
These operational problems are serious. It is Hitachi ID’s opinion that these problems prevent most large
enterprises from completing large-scale E-SSO deployments. Instead, pilots and department-scale de-
ployments, which work reasonably well, hit these roadblocks when trying to scale up, and project scope is
subsequently curtailed.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 4

7. Overcoming Operational Challenges with Traditional E-SSO
4 Is E-SSO More Secure than Password Synchronization?
Many E-SSO vendors claim that E-SSO is more secure than password synchronization. They reason as
follows:
1. If passwords are synchronized, then:
(a) A compromise of one security database will compromise all systems.
(b) An intruder can make more incorrect password guesses before triggering a lockout, since he can
distribute guesses across multiple systems.
2. In contrast, in an E-SSO system, every password is different, so these “vulnerabilities” disappear.
3. Using an E-SSO system together with a two-factor authentication system eliminates passwords alto-
gether. This sounds more secure.
These arguments are very weak, however:
1. Few, if any, modern password databases are vulnerable to total compromise:
(a) Most systems do not make password hashes available to a would-be attacker.
(b) Password guessing attacks depend on weak passwords, which are easy to prevent using either
built-in policies or an external password management system.
(c) Most systems do implement an intruder lockout system, which prevent brute-force attack against
their public authentication mechanism.
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.
2. The argument regarding a higher number of failed authentication attempts before an intruder lockout
is triggered is accurate, but largely irrelevant. If a user has a strong password (this is easy to achieve
– see above), does it really matter if an intruder can try 3, 10 or 100 guesses before being locked out?
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.
3. It’s true – with either password synchronization or E-SSO, if an intruder compromises one password,
he has compromised all passwords for the affected user. In the password synchronization case, an
intruder who compromised any of a given user’s (victim’s) passwords has compromised them all,
since they are the same. In the E-SSO case, an intruder who has compromised the victim’s primary
password has compromised them all: the others can be decrypted using the primary password and
the E-SSO product will obligingly log the intruder into those systems anyways.
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.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 5

8. Overcoming Operational Challenges with Traditional E-SSO
4. Using stronger authentication technologies sounds good, but the application passwords are still there
– still encrypted using a primary key and still used to log into each application. Moreover, when
deploying stronger primary authentication, the method used to generate or acquire the key which de-
crypts all the user’s application passwords is often obscure and in some cases is easily compromised.
In other words, strong primary authentication is often accompanied by weak encryption of sensitive
application passwords.
5 Login Manager: A New Approach to 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.
Hitachi ID 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:
• When users sign into their workstations, Login Manager acquires their network login ID and password
from the Windows login process.
• Login Manager may (optionally) acquire additional login IDs (but not passwords) from the user’s Active
Directory profile.
• Login Manager monitors the Windows desktop for newly launched applications:
– It detects when the user types one of his known login IDs or his Windows password into an
application dialog box, HTML form or mainframe terminal session. When this happens, the
location of the matching input fields is stored on a local configuration file.
– Whenever Login Manager detects an application displaying a previously configured login screen,
it automatically fills in the appropriate login ID and/or the current Windows password.
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:
• Interfering with user access to applications from devices not equipped with the SSO software, such
as their smart phones.
• Having to deploy a secure location in which to store application credentials.
• Writing scripts.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 6

9. Overcoming Operational Challenges with Traditional E-SSO
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 tech-
niques:
• There is no global directory or database with user credentials:
– There is no target for a would-be attacker.
– There is no single point of failure which could cause a widespread disruption to users who wish
to sign into applications.
– There is no need to enroll users by having them provide their passwords.
• There are no manually written scripts:
– No manual configuration is required.
– No infrastructure is required to distribute script files to PCs.
• Continued access to applications:
– Users sometimes need to sign into application from devices other than their work PC.
– Since passwords are synchronized and users know their own password, they can still sign in,
even without the SSO software.
– In contrast, with other E-SSO products, users may not know their own application passwords.
This disrupts application access using a smart phone, home PC, Internet kiosk, etc.
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:
• The set of login IDs associated with a given user is known.
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.
• Passwords are consolidated or synchronized.
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.
• Users sign into their workstations with a password.
Since Login Manager acquires a user’s primary network password from the Windows login process,
that process must itself use a password.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 7

10. Overcoming Operational Challenges with Traditional E-SSO
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.
www.Hitachi-ID.com
500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com
File: /pub/wp/documents/problems-with-traditional-sso/problems-with-traditional-sso
Date: 2006-10-17