Successful Enterprise Single Sign-on Addressing Deployment Challenges

Successful Enterprise Single Sign-on
Addressing Deployment Challenges
© 2014 Hitachi ID Systems, Inc. All rights reserved.

Contents
1 Introduction 1
2 Background: User Problems with Passwords 2
3 Approaches to Simplifying Password Management 3
3.1 Replacing silo authentication with a directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Passing assertions about user identity from one system to another . . . . . . . . . . . . . . 3
3.3 Replacing web application signons with shared infrastructure . . . . . . . . . . . . . . . . . 3
3.4 Synchronizing passwords between systems and across domains . . . . . . . . . . . . . . . 4
3.5 Automatically populating login prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Other Authentication Factors and the Persistence of Passwords 6
5 Traditional Approaches to Enterprise Single Sign-on 7
6 Deployment Blockers: Encryption and Boundary Conditions 8
6.1 Encryption, Primary Passwords and Key Recovery . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 Devices Without E-SSO Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7 Combining Approaches To Single Sign-on 11
8 Extra Security: Boundary Conditions Revisited 14
9 Summary 15
i

Successful Enterprise Single Sign-on: Addressing Deployment Challenges
1 Introduction
This document summarizes the problems users experience when managing too many passwords. It de-
scribes the various approaches available to organizations to reduce the password burden on users and to
improve the security of their authentication systems.
Given this background information, this document goes on to describe the basic architecture of traditional
enterprise single sign-on (E-SSO) systems. It describes their strengths, along with their security, usability
and cost issues.
Finally, a new approach is presented, to deliver most of the same advantages of a traditional E-SSO system
but without any of the traditional issues. The new approach replaces a database of stored passwords with
a password synchronization process. This is the approach embedded in Hitachi ID Login Manager.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

2 Background: User Problems with Passwords
Users who must manage multiple passwords to corporate systems and applications have usability, security
and cost problems.
Users have too many passwords. Each password may expire on a different schedule, be changed with a
different user interface and be subject to different rules about password composition and reuse.
Some systems are able to force users to select hard-to-guess passwords, while others are not. Some
systems require that users change their passwords periodically, while others cannot enforce expiration.
Users have trouble choosing hard-to-guess passwords.
Users have trouble remembering passwords, because they have too many of them or because they chose
a new password at the end of the day or week, and didn’t have an opportunity to use it a few times before
going home.
These problems drive users to choose trivial passwords, to avoid changing their passwords and to write
down their passwords. All of these behaviors can compromise network security.
When users do comply with policy and regularly change their passwords to new, hard-to-guess values, they
tend to forget their passwords and must call the help desk.
Password and login problems are the top incident type at most IT help desks, frequently accounting for 25%
or more of total call volume.
In addition to the above security and support cost problems, users simply don’t like memorizing and typing
passwords. Password management is a nuisance that contributes to a negative perception of IT service.
Despite all these problems, passwords will continue to be needed for years to come:
1. Passwords are signiﬁcantly less expensive to deploy and support than other technologies.
2. Other authentication technologies, such as biometrics, smart cards and hardware tokens, are typically
used along with a password or PIN. i.e., “something you have” (smart card, token) or “something you
are” (biometric) plus “something you know” (password, PIN).
3. Passwords are an important backup to other authentication technologies:
(a) Hardware devices can be lost or stolen or simply left at home.
(b) Some devices from which users need to access corporate systems, such as smart phones and
home PCs, may not support more advanced authentication methods.
Since passwords are not going away and remain difﬁcult for users to manage, solutions are needed to help
users more effectively manage their passwords.

3 Approaches to Simplifying Password Management
There are multiple approaches to reducing password problems for both end users and IT organizations.
These approaches are complementary – organizations can and most do deploy more than one:
3.1 Replacing silo authentication with a directory
Most organizations have deployed at least one enterprise-wide directory. This may be Active Directory
(Microsoft), eDirectory (Novell) or another LDAP-based system (typically Sun or IBM).
Many applications can be configured to validate login IDs and passwords on the directory rather than locally
in application-specific security databases. Doing this reduces administration burden on IT (fewer login
accounts to provision and support) and on users (fewer login IDs and passwords to remember).
This strategy is attractive and should be pursued wherever possible. Its limits are primarily (a) applications
that do not support authenticating users against an external directory and (b) organizational boundaries
that do not permit an application in one domain to authenticate users using a directory in another domain.
3.2 Passing assertions about user identity from one system to another
In Windows/Active Directory networks, user workstations are assigned a Kerberos ticket when users sign
in. The ticket is an encrypted file with assertions about the user’s identity and security group memberships.
The workstation can pass this ticket, avoiding the need for further authentication, to applications that have
been configured with “Windows integrated authentication.”
Similarly, one web site can be configured to trust another site, which has already authenticated a visiting
user. The identity of the user, as claimed by one site, is passed to another site using federation protocols
such as SAML, WS-Federation, Liberty Alliance and Shibboleth.
The approach of having one system authenticate a user and pass assertions about the user’s identity is an
attractive solution where it is technically feasible to implement the trust mechanism between applications
and where the trust relationship is based on real trust between the organization that operates one system
and the organization that operates another.
3.3 Replacing web application signons with shared infrastructure
Applications which are accessed using a web browser are especially amenable to a strategy of replacing
internal authentication with a shared directory infrastructure. A whole class of web single sign-on products
(WebSSO) allows organizations to replace application-specific credentials with a shared directory.
WebSSO systems work by intercepting user attempts to access an application, checking whether the user
has already been authenticated, possibly diverting the user to a shared login system and ultimately injecting
user identity information into the web session. This may be done by adding agents on each web server or
by placing a reverse web proxy server between users and web applications, which modifies the HTTP(S)
data stream.

WebSSO systems are also attractive, and should be used where possible. Their limitation is their platform
– they do not work for terminal sessions, client/server applications and any other system whose communi-
cation protocol is other than HTTP(S).
3.4 Synchronizing passwords between systems and across domains
Even after directory consolidation and web single sign-on have been deployed, there often remain multiple
passwords per user. Users typically continue to have a login ID and password on the network (often Active
Directory), e-mail system (often Exchange or Lotus Notes), ERP system (typically SAP R/3, PeopleSoft or
Oracle eBusiness Suite), a mainframe system (RACF, ACF2 or TopSecret) and possibly a variety of custom
or vertical applications, which may have a Unix or database back end. Increasingly, users also have logins
on externally hosted applications – Salesforce.com, Google Applications, etc.
An effective strategy to approaching the remaining complexity is to install a system that captures password
changes on one system and forwards new passwords to other systems. This way, users still technically
have multiple passwords, but they happen to be set to the same value at all times, eliminating the need to
remember multiple passwords, change them in multiple places, etc. This approach is password synchro-
nization.
Password synchronization is attractive because it is relatively inexpensive to acquire and deploy. There is
no need for client software, user training, etc.
The limitations of password synchronization are (a) that it requires explicit integrations with each password
database and (b) that users still have to type their passwords.
3.5 Automatically populating login prompts
Another approach to reducing password complexity for users is to leave password systems in place but
to automatically populate them when required. This moves the responsibility of remembering and typing
multiple login IDs and passwords from users to an automated process.
This approach is the “enterprise single sign-on” (E-SSO) method. Typically, a set of application login ID /
password pairs is stored for every user. Storage may be in an encrypted ﬁle, in a central database or in an
extension to a network operating system’s security directory – typically Microsoft Active Directory or Novell
eDirectory.
E-SSO is attractive because it addresses not only the user burden of remembering multiple passwords, but
also the user nuisance of having to type them repeatedly. It also allows organizations to deploy a primary
authentication system such as smart cards or one-time-password tokens instead of passwords, without
having to rearchitect every password-secured application.
The limitations of E-SSO include:
1. Incompatibility with a variety of applications, including many Java applets and other kinds of applica-
tions that draw their user interface as a bitmap, rather than using UI elements of the operating system
– input ﬁelds, buttons, etc.
2. The need to store application passwords somewhere – this raises security concerns and creates a

single point of failure.
3. The likelihood that users may not know their own application passwords, which makes users depen-
dent on the E-SSO system. They may not be able to access applications using a smart phone, voice
phone or Internet kiosk, for example.

4 Other Authentication Factors and the Persistence of Passwords
Many argue that passwords have intrinsic limitations:
1. They are awkward to use.
2. They are insecure.
Both of these points are debatable – for example, passwords have the distinct advantage of requiring no
special hardware and being absolutely portable, and passwords that are sufficiently complex and changed
often enough can be quite secure.
Nonetheless, many organizations address these (perceived or real) limitations of passwords by deploying
other authentication technologies.
Authentication is fundamentally based on one or more of three approaches or three types of authentication
factors:
1. Something the user knows but others do not – often a secret PIN, password or phrase.
2. Something the user has but others do not – often a smart card, one time password calculator (token)
or proximity badge.
3. Something the user is but others are not – this is a biometric measurement of some aspect of the
user, such as a finger print, finger vein pattern, retina or iris scan, palm print, voice print or even the
personal cadence with which a user presses keys on the keyboard.
Authentication factors other than passwords are rarely used alone. They are usually accompanied into
a multi-factor authentication system, which is considered more secure than single factor authentication.
Following are the most common systems:
1. One time password (OTP) token, plus password or PIN.
2. Smart card, plus password or PIN.
3. Biometric, plus password or PIN.
The presence of a password or PIN in each of the above combinations indicates that passwords (and PINs
are just short, numeric passwords) normally remain in widespread use even in those organizations that
“replace” passwords with other technologies.
Most of the above systems also requires a backup authentication method. For example, a smart card user
may forget their smart card at home or wish to access web-mail or another application from a device not
equipped with a smart card reader. These users often have a backup, very complex passwords. Similarly,
users who have trouble with their OTP token may request an emergency access code and users who wish to
access an application from a device without a finger print or finger vein reader will need a backup password.
These “boundary condition” scenarios highlight the need to continue to support passwords alone as a
backup authentication method, or risk losing access to systems and applications in some situations.

5 Traditional Approaches to Enterprise Single Sign-on
A traditional E-SSO system incorporates several components:
• A credential database
Stores encrypted application login IDs and passwords for every user. This may be in a file, the user’s
directory object or a database.
• Client software
Detects when applications are launched and inserts credentials from the database into login prompts.
• Scripts
Tell the client software what credentials to populate into which fields on the screen.
These components interact in a variety of ways:
• Deployment
The E-SSO client software is installed on user workstations. Scripts are also initially deployed and
may be periodically updated.
• Script Development
A developer, system administrator or even end users writes scripts for every application that will be
integrated. A graphical framework may be provided to assist.
• Enrollment
A script may detect a user’s first use of an application and capture the user’s login ID and password.
• Password change
A script may detect when a user’s password in an application has expired (i.e., the application asks
the user to choose a new password). In this case, the script may either ask the user to choose a new
password or may generate a random password. Regardless, the new password will be inserted back
into the credential database.

6 Deployment Blockers: Encryption and Boundary Conditions
6.1 Encryption, Primary Passwords and Key Recovery
As described earlier, a key component of a traditional E-SSO system is the credential database. Since it
contains sensitive data specific to a given user, it must be encrypted, and each user should have a different
encryption key. To prevent unauthorized access to application passwords by anyone other than the intended
user, the key is based on the user’s primary authentication.
This is a very important point and bears repeating: application passwords are encrypted using an encryption
key derived from the user’s primary authentication.
This fact leads to some important problems. Different problems arise depending on how users are authen-
ticated in the first place:
Primary
authentication
Operational and security problems that result
Password If a user forgets his primary password, he effectively loses access to all of his other
passwords.
To address this, the E-SSO system must provide a second credential database, normally
on a central server infrastructure, which uses a shared (not user specific) encryption key.
This second credential database is used to reset forgotten primary passwords without
having to recover or replace each and every application password as well.
Deploying a secondary credential database adds cost to the system and raises a
security risk – the secondary system is an attractive target for intruders.
Smart card If a user loses his smart card, he is locked out of every application, not just the primary
PC login.
A backup credential database is needed in this case as well, for the same reasons and
with the same problems as above.
One time
password
There is no way to generate a static, secret encryption key from an OTP pass-code. It
follows that the credential database must be encrypted using a shared or hidden key,
rather than using a key calculated from something the user typed or plugged in.
An intruder may be able to find the encryption key in this scenario and use it to unlock at
a minimum every application password for a single user and at worst every application
password for every user.
Biometric
sample
There is no way to compute a consistent, static, secret encryption key from a biometric
measurement of a user.
This means that, as with one time passwords, the credential database is encrypted
using a key that is available in the user’s absence. An intruder may be able to find the
key and unlock either all of the user’s passwords or possibly every password belonging
to every user.

Primary
authentication
Operational and security problems that result
Proximity card It is possible to store an encryption key on a proximity card, but the key may be
vulnerable to disclosure using an unauthorized RFID reader. Some implementations
may also use a hidden key that as with biometrics and OTP tokens. In any case, at least
the user’s passwords, and possibly all passwords, may be vulnerable.
To summarize the foregoing, storing user passwords in a credential database may lead to some combination
of the following problems:
• Application passwords are lost if the user forgets his primary password; or
• A second credential database is required, adding to system cost and creating a security exposure; or
• The credential database is vulnerable in whole or in part to an intruder who ﬁgures out where the
encryption key, which is not calculated based on user interaction, is stored.
These are all serious problems!
6.2 Devices Without E-SSO Clients
Another issue that arises when application passwords are stored in a credential database is that, over time,
users come to depend on this database and may no longer know their own password.
This is not a problem when users sign into applications from a computer equipped with the E-SSO software,
but creates issues when a user attempts to sign into the same application from another device.
Users increasingly access applications using smart phones, using their home PCs, using Internet kiosks
and even using a telephony / voice user interface. In a typical E-SSO software deployment, none of these
devices is equipped with the E-SSO client software, so none of these devices is able to access the credential
database and use it to sign the user into applications.
This creates a serious usability problem: while the E-SSO software may work well from the user’s work
computer, it also makes applications inaccessible on other devices. This is contrary to the trend of an
increasingly mobile workforce using an increasingly wide array of devices to access the network.
There are various approaches to overcoming this problem, but none of them is satisfactory:
1. Do not allow the E-SSO software to choose new application passwords when old ones expire.
(a) Pro: the user chooses new passwords so hopefully remembers them.
(b) Con: runs contrary to the main business driver of E-SSO – reducing the number of passwords
users must remember.
(c) Con: relies on user behaviour to work. Users may quickly forget passwords they chose if they
do not have to use them on a daily basis.

2. Expose a user interface, such as an authenticated web page, that allows users to read their own
application passwords.
(a) Pro: simple infrastructure that enables users to sign into applications from their smart phones,
home PCs, etc.
(b) Con: frustrating human interface – users must first sign into the device (which has no E-SSO
client), then sign into the application password recovery application, then get the password they
need, then sign into the application they actually want to access and manually type it in. E-SSO
– reducing the number of passwords users must remember.
(c) Con: the password disclosure application becomes an attractive target for intruders.
3. Use Windows Terminal Services or Citrix Presentation Manager as a front end to all remote access to
applications. Require users with non-traditional devices to first sign into a remote-control server farm
and from there, with benefit of the E-SSO infrastructure, sign into applications.
(a) Pro: enables users to sign into applications from their smart phones, home PCs, etc.
(b) Con: very expensive server infrastructure.
(c) Con: requires new client software (terminal services / ICA) on a wide range of user devices.
(d) Con: does not support offline operation – users can only access applications deployed this way
while they are connected to the Internet or corporate network.

7 Combining Approaches To Single Sign-on
The previous sections outline some of the approaches to reducing password complexity and some of the
challenges that arise with enterprise single sign-on (E-SSO) in particular.
In practice, there is no reason to use just one approach. Best practice is most likely to combine:
1. Directory consolidation, typically leveraging Active Directory as the security database used by both
client/server and web applications.
2. Kerberos authentication, where technically possible.
3. Web single sign-on, to consolidate authentication into farms of web applications.
4. Password synchronization, to reduce the number of remaining passwords that users must manage.
5. E-SSO to auto-populate remaining application passwords for users.
A review of the deployment challenges specific to E-SSO, as described in the previous section, highlights
the fact that a key challenge is building, populating, supporting and securing the credential database.
With this in mind, a new approach can be considered: eliminating the credential database entirely and
replacing it with a password synchronization process. This is precisely the approach taken by Hitachi ID
Login Manager.
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.
Login Manager is installed as a simple, self-contained MSI package. It does not require a schema extension
to Active Directory.
The Login Manager architecture is illustrated in Figure 1.
Login:GINAsubsystem
Hitachi ID
Login Manager
Local
configuration
file
Corporate
Directory
Hook
Hook
Hook
What did the user type?
Who
logged
in?
Which window
is active?
Which apps use
Windows credentials?
Acquire
other
login IDs
Auto-fill the user’s
login ID & password
1
2
5
6
4
3
Windows PC
Input event queues
Display subsystem:
windows/dialog boxes
Application
Windows
Figure 1: Login Manager: Internal Components / Architecture
In the diagram:
1. All Login Manager software is local to a user’s Windows workstation, and is (silently) installed using
an MSI package.
2. Other than at installation time, the Login Manager client software does not interact with any server
components. At most, it loads a set of alternate login IDs, associated with the same user, from the
user’s Active Directory object at login time.
3. The core Login Manager software runs as a privileged service, with hooks into the login system
(GINA), the display system and various event queues.
4. When a user logs in, Login Manager acquires that user’s Windows login ID and password. It then:

(a) Optionally, looks up the user’s profile in the corporate directory, assuming the workstation is
connected to the network at the time, to find alternate login IDs that belong to the same user.
(b) Looks for and, if it finds it, reads a configuration file, that identifies which applications are already
known to have login IDs and passwords that are the same as Windows.
5. Whenever a user launches a new application, Login Manager:
(a) Checks to see if it is already a “known application,” and if so auto-populates credentials into the
appropriate dialog.
(b) If the application is not recognized, Login Manager watches to see what the user types to log in
and if it detects login IDs and passwords that are identical to those from step 4, it records the
application’s identifying characteristics (e.g., process ID, Window title, etc.) in the configuration
file mentioned in step 4b.

8 Extra Security: Boundary Conditions Revisited
In some cases, organizations have a legitimate reason to prevent users from knowing their own application
passwords. For example, consider a legacy client/server application, where:
1. Users sign into the client GUI application with a login ID and password.
2. The GUI application uses the user-supplied credentials to connect to the application’s back-end
database.
3. The client GUI is responsible for all access control enforcement.
4. The user’s password actually has unlimited privileges on the back-end database.
The security ﬂaw in this architecture is that the user could connect directly to the back end database with its
native SQL client – for example, sqlplus for Oracle databases, isql for Microsoft SQL Server, etc. Using
this connection, the user could bypass all of the application’s access control rules.
While this is clearly a broken security model, applications built this way remain widely deployed.
The security compromise described here can be avoided by regularly changing the user’s application pass-
word and not allowing the user to know what that password is. Instead, the user is “locked into” the E-SSO
client, which is the only entity that can retrieve the user’s password and sign the user into the application.
This scenario can be implemented by combining three Hitachi ID Systems products:
1. Hitachi ID Password Manager captures each user’s primary (typically Active Directory) password and
stores it, for future use as an encryption key.
2. Hitachi ID Privileged Access Manager randomizes every user’s password on the insecure application,
daily. It uses the user’s primary password (captured by Password Manager) as the encryption key, to
encrypt the application password and store it in the user’s directory object.
3. Hitachi ID Login Manager uses the user’s primary password (acquired at workstation login time) to
decrypt the application password in the user’s directory object. It feeds this password into the insecure
application when required.
The obvious downside of this scenario is that users can only sign into insecure applications from computers
equipped with Login Manager – they cannot sign in from a smart phone, home PC, etc. That is the price for
locking down insecure applications.

9 Summary
Hitachi ID Login Manager, a module included with Hitachi ID Password Manager, is an enterprise single
sign-on solution. It automatically signs users into applications where the ID and/or passwords are the same
ones users type to sign into Windows on their PC.
Login Manager leverages password synchronization instead of stored passwords. This means that it does
not require a wallet and that users can continue to sign into their applications from devices other than their
corporate PC – such as a smart phone or tablet – for which a single sign-on client may not be available.
Login Manager does not require scripting or a credential vault, so has a much lower total cost of ownership
(TCO) than alternative single sign-on tools.
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.
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: /home/idan/work/documents/ps-sso/hid-login-manager-2.tex
Date: 2009-04-07

Successful Enterprise Single Sign-on Addressing Deployment Challenges

Recommended

Recommended

More Related Content

More from Hitachi ID Systems, Inc.

More from Hitachi ID Systems, Inc. (20)

Recently uploaded

Recently uploaded (20)

Successful Enterprise Single Sign-on Addressing Deployment Challenges