Overcoming Operational Challenges with Traditional Approaches to Enterprise Single Sign-On

Overcoming Operational Challenges with

Traditional Approaches to

Enterprise Single Sign-On

© 2014 Hitachi ID Systems, Inc. All rights reserved.

http://Hitachi-ID.com/

http://Hitachi.com/

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

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 musttype 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 presentedby the E-SSO client software.

• A local file, a network-attached database or a user directory stores each user’s ID and password, foreach system and application to which that user has access.

• When a user launches an application on their workstation, the E-SSO client software automaticallypopulates 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 passwordon behalf of the user. The user continues to have multiple ID/password pairs, but does not have to typethem 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, ortwo ID/password pairs if the user must first log into the workstation (e.g., Windows login) and subsequentlyinto the E-SSO client software.

Some E-SSO systems support use of authentication technologies other than passwords to sign into theworkstation and retrieve the user’s application passwords. This may include smart cards, authenticationtokens or biometric samples.

Application login IDs and passwords may be stored on a smart card, rather than on the user’s workstationor on the network.

© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1


2.2 Web Single Sign-on

This document does not pertain to Web Single Sign-on (WebSSO) applications, but they are described herefor completeness:

A Web access management (WebAM) / Web single sign-on (WebSSO) system is middleware used tomanage authentication and authorization of users accessing one or more web-enabled applications. Issupports 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 eitherverifies that the user had already been authenticated (typically tracking authentication state in a cookie) orelse redirects the user to an authentication page, where the user may use a password, token, PKI certificateor other method to authenticate himself.

Once a user is authenticated, the WebAM component of the system controls the user’s access to applicationfunctions 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 displaycertain 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, whichenables 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 areappropriate to both Intranet (thousands of high-value, high-complexity, low transaction-volume users) andExtranet (millions of low-value, low-complexity, high transaction volume) use.

WebSSO / WebAM products are available from major platform vendors. Most of these were acquired fromsmaller, 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 areunsuitable to managing complex users with multiple accounts on multiple systems, as they have no conceptof 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 somehowbad (compromise one password and all are compromised).

An alternate approach to single sign-on, described later in this document, is actually based on passwordsynchronization.



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 onan enterprise network:

• Users with synchronized passwords tend to remember their passwords.

• Simpler password management means that users make significantly fewer password-related calls tothe 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 ona common system (example: Active Directory) are automatically propagated through the passwordmanagement system to other systems and applications.

• Web-based password synchronization, where users are asked to change all of their passwords atonce, 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 beencoded in different ways and stored on various media but fundamentally it is a set of login ID / passwordpairs that the E-SSO application will type on behalf of the user when each application prompts for loginverification. This data must be available for every user.

Previous approaches to enterprise single sign-on systems had problems, all related to the password databasewhere 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 choosingnew, random password values, allowing the application to change passwords and storing the randompassword value for future reference.

With this process in place, over time users lose knowledge of their own passwords and becomedependent on the E-SSO system to sign into their applications. This means that users cannot accesstheir applications from devices that are not equipped with the E-SSO software, such as smart phonesor even their home PCs.

• Cost to Deploy:

Building and maintaining a database of every login ID and every password on every application canbe both costly and time consuming.



• 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 losethis key and can no longer decrypt their application passwords. As a result, password problems maybe 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 IDand 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 ajustification for cross-selling other products:

1. Some vendors create a mechanism for users to display their own plaintext passwords, when accessingapplications from non-traditional devices. This is, of course, insecure.

2. Citrix uses the remote-availability problem to encourage customers to migrate their users to CitrixPresentation Manager. If users access every application by remote control, and the terminal servicesservers 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 privilegedcredential and so to address the problem of expensive password resets. This can create securityweaknesses and/or administration headaches.

These operational problems are serious. It is Hitachi ID’s opinion that these problems prevent most largeenterprises 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 issubsequently curtailed.



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 asfollows:

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 candistribute 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 eitherbuilt-in policies or an external password management system.

(c) Most systems do implement an intruder lockout system, which prevent brute-force attack againsttheir public authentication mechanism.

As a result, a compromise of any one security database is quite unlikely. If such a compromise wereas 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 lockoutis 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 theorder of 50 – 100 failed attempts) anyways. A low count is no substitute for strong passwords andif passwords are strong, there is no harm in setting the counter high, since the password will not beguessed 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, anintruder 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 primarypassword has compromised them all: the others can be decrypted using the primary password andthe 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 thesingle 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.



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, whendeploying 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 sensitiveapplication 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 improvethe user experience, by reducing the number of times that a user, in a given day, must type his ID andpassword.

The problem with E-SSO is basically the credential database – it is expensive to acquire and maintain, isan attractive target for attackers and prevents users from accessing applications from devices that are notequipped 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 passwordfrom the Windows login process.

• Login Manager may (optionally) acquire additional login IDs (but not passwords) from the user’s ActiveDirectory 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 anapplication dialog box, HTML form or mainframe terminal session. When this happens, thelocation 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 passwordsthat 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, suchas 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 extensionto 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 wishto 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 LoginManager.

In order to achieve its benefits of low cost and high availability, Login Manager makes three importantassumptions:

• 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 generatelogin ID aliases using a combination of automation and self-service enrollment and can write this datato the user’s profile in Active Directory or eDirectory. Login Manager can retrieve this list of login IDsat login time.

• Passwords are consolidated or synchronized.

Since Login Manager does not store a user’s passwords anywhere, it depends on a user’s applicationpasswords 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.



Combining Login Manager with other authentication technologies, such as smart cards or one timepassword tokens, may require extra integration effort, so that Login Manager can retrieve the user’ssynchronized 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: [email protected]

File: /pub/wp/documents/problems-with-traditional-sso/problems-with-traditional-sso-1.texDate: 2006-10-17

http://Hitachi-ID.com/

Technology

Overcoming Operational Challenges with Traditional Approaches to Enterprise Single Sign-On