Successful Enterprise Single Sign-on: Addressing Deployment Challenges

Successful Enterprise Single Sign-on

Addressing Deployment Challenges

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

http://Hitachi-ID.com/

http://Hitachi.com/

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 toimprove the security of their authentication systems.

Given this background information, this document goes on to describe the basic architecture of traditionalenterprise single sign-on (E-SSO) systems. It describes their strengths, along with their security, usabilityand cost issues.

Finally, a new approach is presented, to deliver most of the same advantages of a traditional E-SSO systembut without any of the traditional issues. The new approach replaces a database of stored passwords witha 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, securityand cost problems.

Users have too many passwords. Each password may expire on a different schedule, be changed with adifferent 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. Somesystems 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 chosea new password at the end of the day or week, and didn’t have an opportunity to use it a few times beforegoing home.

These problems drive users to choose trivial passwords, to avoid changing their passwords and to writedown 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, theytend 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 typingpasswords. 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 significantly less expensive to deploy and support than other technologies.

2. Other authentication technologies, such as biometrics, smart cards and hardware tokens, are typicallyused along with a password or PIN. i.e., “something you have” (smart card, token) or “something youare” (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 difficult for users to manage, solutions are needed to helpusers 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 locallyin application-specific security databases. Doing this reduces administration burden on IT (fewer loginaccounts 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) applicationsthat do not support authenticating users against an external directory and (b) organizational boundariesthat 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 signin. 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 havebeen configured with “Windows integrated authentication.”

Similarly, one web site can be configured to trust another site, which has already authenticated a visitinguser. The identity of the user, as claimed by one site, is passed to another site using federation protocolssuch 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 anattractive solution where it is technically feasible to implement the trust mechanism between applicationsand where the trust relationship is based on real trust between the organization that operates one systemand 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 replacinginternal 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 userhas already been authenticated, possibly diverting the user to a shared login system and ultimately injectinguser identity information into the web session. This may be done by adding agents on each web server orby 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 multiplepasswords per user. Users typically continue to have a login ID and password on the network (often ActiveDirectory), e-mail system (often Exchange or Lotus Notes), ERP system (typically SAP R/3, PeopleSoft orOracle eBusiness Suite), a mainframe system (RACF, ACF2 or TopSecret) and possibly a variety of customor vertical applications, which may have a Unix or database back end. Increasingly, users also have loginson externally hosted applications – Salesforce.com, Google Applications, etc.

An effective strategy to approaching the remaining complexity is to install a system that captures passwordchanges on one system and forwards new passwords to other systems. This way, users still technicallyhave multiple passwords, but they happen to be set to the same value at all times, eliminating the need toremember 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 isno need for client software, user training, etc.

The limitations of password synchronization are (a) that it requires explicit integrations with each passworddatabase 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 butto automatically populate them when required. This moves the responsibility of remembering and typingmultiple 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 file, in a central database or in anextension to a network operating system’s security directory – typically Microsoft Active Directory or NovelleDirectory.

E-SSO is attractive because it addresses not only the user burden of remembering multiple passwords, butalso the user nuisance of having to type them repeatedly. It also allows organizations to deploy a primaryauthentication system such as smart cards or one-time-password tokens instead of passwords, withouthaving 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 fields, 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, voicephone 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 nospecial hardware and being absolutely portable, and passwords that are sufficiently complex and changedoften enough can be quite secure.

Nonetheless, many organizations address these (perceived or real) limitations of passwords by deployingother authentication technologies.

Authentication is fundamentally based on one or more of three approaches or three types of authenticationfactors:

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 theuser, such as a finger print, finger vein pattern, retina or iris scan, palm print, voice print or even thepersonal cadence with which a user presses keys on the keyboard.

Authentication factors other than passwords are rarely used alone. They are usually accompanied intoa 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 PINsare 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 usermay forget their smart card at home or wish to access web-mail or another application from a device notequipped 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 toaccess 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 abackup 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’sdirectory 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 andmay be periodically updated.

• Script Development

A developer, system administrator or even end users writes scripts for every application that will beintegrated. 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 asksthe user to choose a new password). In this case, the script may either ask the user to choose a newpassword or may generate a random password. Regardless, the new password will be inserted backinto 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 itcontains sensitive data specific to a given user, it must be encrypted, and each user should have a differentencryption key. To prevent unauthorized access to application passwords by anyone other than the intendeduser, 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 encryptionkey 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:

Primaryauthentication

Operational and security problems that result

Password If a user forgets his primary password, he effectively loses access to all of his otherpasswords.

To address this, the E-SSO system must provide a second credential database, normallyon a central server infrastructure, which uses a shared (not user specific) encryption key.This second credential database is used to reset forgotten primary passwords withouthaving to recover or replace each and every application password as well.

Deploying a secondary credential database adds cost to the system and raises asecurity 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 primaryPC login.

A backup credential database is needed in this case as well, for the same reasons andwith the same problems as above.

One timepassword

There is no way to generate a static, secret encryption key from an OTP pass-code. Itfollows 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 ata minimum every application password for a single user and at worst every applicationpassword for every user.

Biometricsample

There is no way to compute a consistent, static, secret encryption key from a biometricmeasurement of a user.

This means that, as with one time passwords, the credential database is encryptedusing a key that is available in the user’s absence. An intruder may be able to find thekey and unlock either all of the user’s passwords or possibly every password belongingto every user.



Primaryauthentication

Operational and security problems that result

Proximity card It is possible to store an encryption key on a proximity card, but the key may bevulnerable to disclosure using an unauthorized RFID reader. Some implementationsmay also use a hidden key that as with biometrics and OTP tokens. In any case, at leastthe 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 combinationof 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 figures out where theencryption 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 kiosksand even using a telephony / voice user interface. In a typical E-SSO software deployment, none of thesedevices is equipped with the E-SSO client software, so none of these devices is able to access the credentialdatabase 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 workcomputer, it also makes applications inaccessible on other devices. This is contrary to the trend of anincreasingly 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 passwordsusers must remember.

(c) Con: relies on user behaviour to work. Users may quickly forget passwords they chose if theydo 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 ownapplication 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-SSOclient), then sign into the application password recovery application, then get the password theyneed, 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 toapplications. Require users with non-traditional devices to first sign into a remote-control server farmand 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 waywhile 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 thechallenges 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 bothclient/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, highlightsthe 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 andreplacing it with a password synchronization process. This is precisely the approach taken by Hitachi IDLogin Manager.

Login Manager automatically fills in application login IDs and passwords on behalf of users, streamliningthe 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 Login Manager architecture is illustrated in Figure 1.

Lo

gin

: G

INA

su

bsy

stem

Hitachi IDLogin Manager

Localconfiguration

file

CorporateDirectory

Hook

Hook

Hook

What did the user type?

Whologgedin?

Which windowis active?

Which apps useWindows credentials?

Acquireother login IDs

Auto-fill the user’slogin ID & password

1

2

5

6

4

3

Windows PC

Input event queues

Display subsystem:windows/dialog boxes

ApplicationWindows

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 usingan MSI package.

2. Other than at installation time, the Login Manager client software does not interact with any servercomponents. At most, it loads a set of alternate login IDs, associated with the same user, from theuser’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 isconnected 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 alreadyknown 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 theappropriate dialog.

(b) If the application is not recognized, Login Manager watches to see what the user types to log inand if it detects login IDs and passwords that are identical to those from step 4, it records theapplication’s identifying characteristics (e.g., process ID, Window title, etc.) in the configurationfile 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 applicationpasswords. 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-enddatabase.

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 flaw in this architecture is that the user could connect directly to the back end database with itsnative SQL client – for example, sqlplus for Oracle databases, isql for Microsoft SQL Server, etc. Usingthis 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-SSOclient, 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 andstores 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, toencrypt 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) todecrypt the application password in the user’s directory object. It feeds this password into the insecureapplication when required.

The obvious downside of this scenario is that users can only sign into insecure applications from computersequipped with Login Manager – they cannot sign in from a smart phone, home PC, etc. That is the price forlocking down insecure applications.



9 Summary

Hitachi ID Login Manager, a module included with Hitachi ID Password Manager, is an enterprise singlesign-on solution. It automatically signs users into applications where the ID and/or passwords are the sameones users type to sign into Windows on their PC.

Login Manager leverages password synchronization instead of stored passwords. This means that it doesnot require a wallet and that users can continue to sign into their applications from devices other than theircorporate 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 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.

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: /home/idan/work/documents/ps-sso/hid-login-manager-2.texDate: 2009-04-07

http://Hitachi-ID.com/

Technology

Successful Enterprise Single Sign-on: Addressing Deployment Challenges