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 describes 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

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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 significantly 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 difficult for users to manage, solutions are needed to help users more effectively manage their passwords.

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

2

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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.

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

3

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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 communication 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 synchronization.

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 file, 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 applications 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 © 2014 Hitachi ID Systems, Inc.. All rights reserved.

4

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

single point of failure.

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

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

5

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

6

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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.

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

7

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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 authenticated 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.

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

8

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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 figures 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. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

9

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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.

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

10

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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. © 2014 Hitachi ID Systems, Inc.. All rights reserved.

11

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

• 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.

Windows PC What did the user type?

Hook

Input event queues

5 6 Auto-fill the user’s

Which apps use Windows credentials?

3

Local configuration file

Hitachi ID Login Manager

Acquire other login IDs 2

Hook 1

Who logged in?

Which window is active?

4

Hook

Corporate Directory

Login: GINA subsystem

login ID & password

Application Windows

Display subsystem: windows/dialog boxes

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: © 2014 Hitachi ID Systems, Inc.. All rights reserved.

12

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

(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.

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

13

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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 flaw 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 password 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.

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

14

Successful Enterprise Single Sign-on: Addressing Deployment Challenges

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 techniques: • 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.

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

www.Hitachi-ID.com

File: /home/idan/work/documents/ps-sso/hid-login-manager-2.tex Date: 2009-04-07