【转载做哈笔记】single sign-on

Single Sign-On

Jani Hursti
Department of Computer Science
Helsinki University of Technology
1997-11-19
[email protected]

Abstract

Single Sign-On systems consist of the methods designed for securely and easily authenticating users in a heterogeneous computing environment. The aim is to enable authentication without requiring multiple authentication procedures by the user and also easy management of rights by the administrators. This paper discusses different models of Single Sign-On, presents real-life implementations, and evaluates the use and security of these solutions.

Table of Contents

1 Introduction

1.1 Background

1.2 Research Problem and Objectives of the Paper

1.3 Scope of the Paper

1.4 Structure of the Paper

2 Ideal Single Sign-On

3 Implementation Problems

3.1 Problems Related to Computing Environment

3.2 Problems Related to Organizational Structures

3.3 Problems Related to Electronic Identity

4 Single Sign-On Models and Implementations

4.1 Common Standard Solutions

4.1.1 GSS-API

4.1.2 OSF Distributed Computing Environment DCE

4.1.3 Pluggable Authentication Modules PAM

4.2 Broker-Based SSO Solutions

4.2.1 Kerberos

4.2.2 Sesame

4.2.3 IBM KryptoKnight

4.3 Agent-Based SSO Solutions

4.4 Token-Based SSO Solutions

4.5 Agent and Broker-Based SSO Solutions

4.6 Gateway-Based SSO Solutions

5 Assessment of Current Solutions

5.1 Broker-Based

5.2 Agent-Based

5.3 Token-Based

5.4 Gateway-Based

5.5 Agent and Broker-Based

6 Future Development Possibilities

7 Summary

References

1 Introduction

1.1 Background

As the popularity of applications based on computer networking increases, the security market is responding to the risks of open networks. Unforatunately, as new security measures are added, these measures reduce the usability and increase the complexity of management of these systems.

To illustrate the general development of the security solutions, Figure 1.1 presents one model of the growth of the security market and the segments of the market. The X- axis of the figure represents time. The growth pattern of the figure can be recognized in many different areas and thus many different variables can be plotted on the Y- axis. For those in the security business, the growth pattern in Figure 1.1 can be related with the volume and the total revenues of the information security business. The Y-axis also plots the growing knowledge requirements concerning threats towards digital information. Futhermore, it plots the complexity of the underlying networked applications that require security and the complexity of the security solutions. To cope with the complex systems and the high knowledge requirements, the IT managers need tools for managing their security. Secure Single Sign-On SSSO or simply Single Sign-On SSO help the management and the users of a secured distributed computing environment.

Figure 1.1 The Development of the Security Business Segments as a Response for the Increasing Needs of Networked Applications [1]

To show the motivation behind SSO, consider a company that has several departments including finance, marketing, R&D, manufacturing, etc. During the years of operation, the company has purchased several computing systems, some of which are legacy mainframes, some state-of-the-art workstations. Each of these has resources that need to be available for the employees, but in a secure manner. What is needed is systems which provide authentication and authorization. Typically users are entered in a database for each system and they are given a password for the access. To get into the system, the users login by entering a user name and a password. With the heterogeneous systems, the end result is that the users need to have passwords for each system, log-in separately, etc. This is hardly an ideal situation.

The users find it annoying to work in a badly designed, heterogeneous secured environment. Each time they start working they have to enter several passwords to get into all the systems they need. All the passwords have to be remembered and, even worse, changed frequently. When a new employee enters the organizations, it takes a long while before an account is set up to all the needed resources.

For the IT manager, the heterogeneous security system is a nightmare. There are several user databases to manage. Setting up an account is cumbersome, but this is still nothing compared to the situation when someone leaves the organization. No one knows to how many places the individual actually had access. Going through the systems and deleting the used accounts is painstaking.

The security manager is not too happy. Because there are several passwords, the users do not remember to change them frequently enough. Even worse, because they cannot remember the passwords in the first place, the passwords are written down on notes and glued under the desk or behind the computer. Because of the cumbersome login procedures, the users avoid logging in and leave themselves logged in. This leaves the systems vulnerable for internal attacks.

The idea behind Single Sign-On is that the identity of the users is checked only once and the electronic identity is transferred to different computing resources securely and automatically. The rights associated with the users and resources are administered in a central manner, so there is no need for the IT managers to worry about several databases.

1.2 Research Problem and Objectives of the Paper

This paper sets out to study Single Sign-On as a technology. The objective of this paper is to describe and summarize the different approaches to Single Sign-On. The reader of the paper should get a clear picture of the current motivations and possibilities of Single Sign-On as well as the implementation problems related to the solutions. The described solutions are then evaluated based on different characteristics. 

1.3 Scope of the Paper

The scope of this paper is restricted to commercially available Single Sign-On models and implementations. The list of systems is intended to be sufficient, but not exhaustive. As many of the implementations require solutions from several areas of security, such as smart cards and cryptography, these are described in some detail, but the paper does not go into specific details of these technologies. The reader is assumed to be familiar with basic networking technology concepts and these concepts are not explained in the paper. 

1.4 Structure of the Paper

An outline of the structure of the research paper is presented in Figure 1.2.

Figure 1.2 Structure of the research paper

2 Ideal Single Sign-On

Before moving into the problem areas and real life implementations, let us define an ideal system we are striving for in Single Sing-On. In the ideal world, everything works smoothly and the computing resources are used in the most beneficial way. Single Sign-On cannot affect everything related to efficient computing, but there are things it can do. Signing-on really means acquiring an electronic identity. Thus it is a mapping from the physical world to the electronic and logical world. In the ideal world, this mapping is secure and convenient. The intended electronic identity is given to only that individual it belongs to. This not only means that the method of identification cannot be attacked against but also that it cannot be used incorrectly. The identification method should not cause extra work, otherwise it will not be used. Extra work is caused by going through the identification process, possibly multiple times. In an ideal system the user does not have to worry about it. It is the computer's problem to recognize him or her. The system needs to be so reliable that the identity can be proven anytime, anywhere. The downtime of the systems needs to be minimal.

As the computing environment has to be administered in some way, the administration should not cause extra work or security holes. The administration procedures should fit the power structures and policies of the surrounding organization. Basically this means that the IT managers are not given rights to control people above them in the hierarchy if not specifically authorized to do so. When a Single Sign-On system is taken into use, the migration should be easy. This means that all the users learn to use the system instantly. The methods of authentication and usage can be distributed and installed throughout the organization without extra effort. There is no down-time which would affect normal working. All the applications, no matter how old or new, instantly accept the new method without any modifications. 

3 Implementation Problems

The ideal world described in chapter 2 is of course idealism that is in several respects far from reality. This chapter describes the reasons why the ideal system cannot currently be reached. These problems mainly relate to the existing organizational structures, the existing computing environment, and the problems of electronic identity. 

3.1 Problems Related to Computing Environment

The main problem of the current computing environment is that it has never been designed for security, not to mention a common authentication method. If a new system of authentication and access control is implemented, for sure the old systems will not interoperate with it.

Trust is the main element of all security solutions. Unfortunately, the current computer systems cannot be trusted upon. They have severe security holes, bugs, and cannot withstand an attack from a malicious party. These untrustworthy components pose a challenge, especially for security software running on untrustworthy platforms.

To make things worse, the main problem actually is not what the security problems of a system are, but what the system is in the first place. The reality is that the IT managers do not even know what their computing environment looks like. They have only vague ideas of the network configuration and all the services available in that network. 

3.2 Problems Related to Organizational Structures

Controlling access to the computing resources is typically made with rules. The rules state which individuals have access to which resources and which individuals do not. To simplify the task, the users are divided into groups with similar needs and rights. Managing the different groups of users can be painstaking, as the users need to be associated with a group that has just the right amount of privileges. When the user moves to another place in the organizational structure, the change has to be reflected in his or her rights on the computing environment also. In a modern team-based organization with a low level of hierarchy and job rotation these changes are frequent and the borders of the groups are vague.

When the difficulties with the organizational structure are combined with the difficulties of the computing environment, the result is obvious. The security and system administrators have to cope with an amoeba-like complex matrix. This matrix is maintained in several databases all based on different paradigms and possibilities of configuration - and confusion. 

3.3 Problems Related to Electronic Identity

The basis of signing on to a system is electronic identification. Several solutions exist with their own pros and cons. These are based on combinations of three basic models: something known, something held, or something embodied. A traditional solution is to select just one of these, something known, and use a password authentication. This authentication method is vulnerable because of password guessing and password sniffing on a network. Too simple passwords that are not changed and are written on notes glued near the computer are a major threat to security.

Stronger methods of authentication are available. One-time password systems are based on a series of passwords that are used only once, making password sniffing useless. The passwords can be written on a list or generated by an electronic device.

The electronic identity can also be based on a smart card. The card typically holds a secret that is protected by a password. The password has to be entered in conjuction with the card. The secret can be a cryptographic key that is used to answer a challenge given by the authentication server. The cryptographic methods, such as RSA authentication, can be used without smart cards, too.

The something embodied methods use biometrical measurements that are still too expensive to be feasible, although progress is being made in several areas. For example, there exists a product for identifying users based on their handwriting.

Once the authentication is done securely, the next challenge is to make every system accept the same electronic identity. This means generating credentials for the user and passing those automatically to all needed services. This is possibly the toughest part in the implementation. 

4 Single Sign-On Models and Implementations

This chapter introduces different approaches and possibilities of SSO. First, some general standard solutions are presented. These are used for building and supporting SSO. Next, the actual SSO implementations are described. 

4.1 Common Standard Solutions

4.1.1 GSS-API

The Generic Security Service Application Program Interface GSS-API defines an interface to cryptographically strong security services including authentication, integrity, and confidentiality of transmitted data [2]. Typically, the GSS-API is called by an another protocol, for example Kerberos. This is why it is used in building different security services and applications, including SSO. A rough illustration of the operational paradigm is presented in Figure 4.1. The aim of the GSS-API is to provide an interface that hides the specific underlying security mechanisms. This hopefully results in better interoperability of different applications.

Figure 4.1 The GSS-API operational paradigm 

4.1.2 OSF Distributed Computing Environment DCE

Open Software Foundation's Distributed Computing Environment DCE is a framework that provides services for running applications in a distributed computing environment with heterogeneous computing resources. As a part of the services, the DCE also provides security. There are four aspects to DCE security: authentication, secure communications, authorization, and auditing [3].

DCE uses an authentication service based on Kerberos [4]. Kerberos is discussed in more detail later in this paper. The Kerberos service is integrated into the management service of the DCE. 

4.1.3 Pluggable Authentication Modules PAM

The Pluggable Authentication Modules PAM is an Application Programming Interface for enabling easy migration between different authentication methods. Many times an operation system or some software application relies on one type of authentication, typically passwords. If a stronger authentication method is needed, the task may involve a lot of re-engineering. The aim of PAM is to provide a way to easily support different authentication methods and to let the system administrators "plug-in" authentication methods at will and configure them in a simple and straightforward manner [5]. 

4.2 Broker-Based SSO Solutions

In a broker-Based SSO solution, there exists one server for central authentication and user account management. The broker gives an electronic identity that can be used for requesting further access. The central database reduces administrative overhead and provides a common, single place for authentication. 

4.2.1 Kerberos

Kerberos is an authentication protocol designed at the Massachusetts Institute of Technology for TCP/IP networks and it is the basic model for a broker-based Single Sign-On. It is based on a trusted server, called the Kerberos server which acts as a broker, centrally authenticates the users, and gives them an electronic identity based on the given credentials. The identity can be used automatically to request for tickets to different services. With a ticket, the client can access to final applications. This process is illustrated in Figure 4.2. All data that is passed through the network is encrypted. Describing the cryptographic protocol used in Kerberos is out of the scope of this paper, but excellent descriptions can be found from http://web.mit.edu/kerberos/www/papers.html. Typically, the Kerberos implementations use GSS-API for the security services.

Figure 4.2 The Kerberos authentication process   [6]  

4.2.2 Sesame

Sesame, Secure European System for Applications in a Multi-vendor Environment, is the European equivalent to Kerberos. Sesame V3 is built on top of GSS-API and it provides Single Sing-On services and the confidentiality of data in a distributed environment. Although Sesame is based on the same paradigms as Kerberos, it is not a one-to-one copy, but instead aims to add several features to the original design. These include heterogeneity, access control features, scalability of public key systems, better manageability, auditing, and delegation [7].

As in Kerberos, the user first authenticates himself to an authentication server. From the authentication server the user gets a token that is again presented to another server to gain access to the final applications. In Sesame, these servers are called Privilege Attribute Servers. From an Privilege Attribute Server, the user gets a Privilege Attribute Certificate PAC which finally gives access rights to the needed service. 

4.2.3 IBM KryptoKnight

The KryptoKnight is an equivalent to Kerberos designed by IBM. The operating model is similar to Kerberos. It uses GSS-API for its security services. The differences to Kerboros are few. Instead of using synchronized clocks and timestamps, KryptoKnight used nonces for authentication. KryptoKnight has also been optimized better, resulting in lower network overhead. It also supports other communication protocols than IP, for example NetBIOS [8]. 

4.3 Agent-Based SSO Solutions

In an agent-Based solution there exists an agent program that automatically identifies the user for different applications. The agent can be designed to function in different ways. For example, it can carry password lists or encryption keys for cryptographic proofs and use these automatically to remove the burden of authentication from the user. The agent can also be placed on the server side to act as an "interpreter" between the authentication system in the server and the authentication method used by the client. An example of an agent-based solution is SSH Communications Security LTD's SSH Agent which is a clint-side agent.

The SSH is a client-server type encryption software system for making secure connections over the Internet. The users of SSH are authenticated using different authentication methods, including RSA cryptographic authentication. When RSA authentication is used, the agent program can be used for Single Sign-On type logins. The agent program is run on a PC, laptop, or terminal. The wanted identities are added to the agent and all new connections are started as children of the agent, thus inheriting the connection to the agent. The SSH-agent can then automatically use the identities stored in it to identify the connection. The remote system needs to have an SSH server running to communicate with the agent [9]. 

4.4 Token-Based SSO Solutions

The Security Dynamics SecurID is a physical token that generates time dependent one-time passwords for the user thus providing two-factor authentication. SecurID is based on synchronized clocks on a hardware token and a server on the network, called the ACE server. At predetermined intervals the token generates new passwords that are unique to the token and accepted only within a given time window. The solution also includes a module called WebID. In WebID solution, an ACE server agent program is installed at a Netscape Suitespot web server and it accepts the passwords generated by SecurID. During the authentication to the first URL, WebID generates a software token which is an encrypted ticket. The ticket can be used as authentication when accessing additional URLs [10]. 

4.5 Agent and Broker-Based SSO Solutions

When the agent-based solution is combined with a broker-based solution both the central management of the broker-based solutions and the flexibility of agent-based solutions can be used. The benefit of the agent approach is the reduced need to change the network applications. And agent that is specifically designed for the type of system the application is running on can accept the centrally granted rights and transform these into a form that is accepted by the application. Thus, compared to Kerberos, there is no need to "kerberize" applications. An example system is the Axent Technologies Enterprise Resource Management ERM.

The Axent Technologies Enterprise Resource Management ERM is based on a similar paradigm as Kerberos. The difference between ERM and Kerberos is that in addition to a central authentication server, the ERM also includes agent software that can be installed on different computing platforms. Figure 4.3 shows a graphic of the model.

Figure 4.3 An Agent and Broker-Based access control solution

There are two types of agents in the ERM. Resource Management Agents reside on the different services on the network. Their task is to enable the ERM to centrally manage the native user databases. They update the changes made to the central database to the native databases and also vice versa. Resource Activation Agents are also placed on the network servers. Their purpose is to grant access to the service [11]. 

4.6 Gateway-Based SSO Solutions

The broker-based solutions provide a model where a "watchdog" is placed in a network. A different approach to Single Sign-On is provided by a gateway approach where there is a "door" to the services inside a trusted network. This door can be a firewall, or in the case of our example, a dedicated cryptographic server. The Algorithmic Research PrivateWire is based on strong cryptography in TCP/IP networks. A model of the solution is presented in Figure 4.4.

Figure 4.4 A Gateway-based access control solution

In the solution, all the requested services need to reside behind the gateway, in a trusted network segment. The clients authenticate themselves cryptographically to the gateway that grants access to the services. As the services behind the gateway can be recognized based on their IP addresses, a rule base based on IP addresses can be built on the gateway. When this rule base is combined with a user database residing on the gateway, the gateway can be used for Single Sign-On. The gateway remembers the identities of the clients and can thus grant access to all the required services without further authentication requests. As the gateway has the possibility to access all the traffic flow to the services, it can monitor and alter the data flowing to the services. Thus it can replace the authentication information going to the services, making it suitable for access control without modifications in the applications themselves [12]. 

5 Assessment of Current Solutions

The presented solutions can be and should be evaluated from several points of view. The most important ones are implementability, administration, security, and usage. Implementability is a function of the complexity of the system and measures how easily the existing computing system can be modified to use the SSO solution. Administration is the administrators point view on how easily the system is used. Security measures how vulnerable the system is to attacks. Usage is the end-user's viewpoint to the system.

5.1 Broker-based

Implementability

The main problem with broker-based solutions, such as Kerberos, is the end applications which need to be modified, or "kerberized" to accept the tickets.

Administration

The central administration is the major strength in broker-based solutions. One central database is easy to manage.

Security

A broker-based solution can be designed to be secure, but the actual level of security depends on the implementation. There are several security issues with Kerberos. First of all, it makes the assumption that the clients are trusted. Based on the assumption that the clients are trustworthy, the attacker can design a malicious client that records passwords. As the tickets are stored in the memory of the clients, much trust is put on the security of the client systems. The system also relies a lot on the servers ability to authenticate users.

The authentication in Kerberos is only based on passwords, thus making the system vulnerable to password guessing. The secret key used for encrypting the initial session key is a one-way has of the users password. Thus guessing the password correctly would allow the attacker to get the session key and to continue to get the final credentials and access rights.

Sesame has mainly the same strengths and weaknesses as Kerberos does, namely the vulnerability to password guessing, and the single-point-of-failure of the Authentication Server. It is also rumored that the French government has put serious restraints to the cryptographic strength of the services, making the implementation less secure than Kerberos [13].

The improvements in cryptography in the KryptoKnight should have made it more secure than Kerberos.

Usage

All the different approaches to Single Sign-On can be designed in such a way that most of the work by the user can be done automatically. Basically, the user needs to learn how to use the client software and how to authenticate himself or herself. This is a design and implementation issue that is not directly related to a certain model. However, the usage is affected by the availability of the service and in broker-based solutions this is critical. Whenever the system has a central component, such as in broker-based solutions, the component is a single-point-of-failure which reduces usage. If that component is down, no-one can log in.

5.2 Agent-based

Implementation

The agent-based approach makes the migration easier, as the software vendor supplies different agents that are designed to communicate with the legacy applications.

Administration

The pure agent approach does not help administration. It can make administration even harder as there are not just the rights of the users to worry about but also the rights of the agents.

Security

An agent that authenticates itself with strong cryptography should be secure. The problem is that an agent which is "loaded" with identities can possibly be used wrong or replaced by malicious software.

Usage

Perhaps approaches such as the SSH Agent that has to specifically be loaded with identities is a hard concept to learn. Also all the concepts of public-key cryptography might be hard to grasp.

5.3 Token-based

Administration

The current token-Based solutions such as WebID increase to administrative workload as one more component is added to the system.

Security

The SecurID hardware token increases the security of authentication. Less data is available on whether the software tokens can be cracked.

5.4 Gateway-based

Implementation

In certain environments a gateway is easy to install and configure. As it is a separate component and is only concerned with the network traffic flowing through it, there should not be interoperability problems. The only problem might be the client software for the applications and the gateway client software which need to reside on the same computer.

Administration

The gateway has central user database and thus should be as easy to manage as a broker-based solution. Problems arise though if several gateway are used and the databases cannot be synchronized automatically.

Security

A cryptographic server should be secure but it can be attacked against. It is possible to attack the underlying operating system. As the gateway sits in the place of a firewall, attacks used against firewalls, such as SYN-flooding, might work here, too. It is thus recommended to protect the gateway with a separate firewall.

Usage

The gateway is a central component that affects the availability and the usage of the system as in a broker-based approach.

5.5 Agent and Broker-based

Implementation

The purpose of the agents is to remove to need to modify the systems like in pure broker- based approaches.

Administration

The administration of an agent and broker -based solution should be even easier that the one of a pure broker-based solution. This is because even the native databases can be administered automatically through administration agents.

Security

The agent approach should add security as the agents can authenticate themselves without sending passwords, encrypted or not, across the network.

Usage

The solution has a central component that affects the availability and the usage of the system as in a pure broker-based approach.

6 Future Development Possibilities

This paper has presented several approaches to Single-Sign-On and described real life implementations. Though real life implementations were discussed, in reality the SSO solutions are far from mature products. Just making the discussed systems work in real environments would seem enough for future development.

The current models can be improved. The efforts should be aimed at better interoperability. This means designing common APIs, such as GSS-API and PAM which are good stating points. Systems should be designed so that they recognize multiple authentication methods and credentials so that for example an agent would accept Kerberos, Sesame, and Axent ERM tickets.

One improvement is a higher level of integration into operating systems and actually there are rumors that operating system vendors such as Microsoft are interested in either supporting or implementing Kerberos or similar systems. 

7 Summary

This paper has discussed Single Sign-On, its motivations, problem areas, models, and implementations. The models presented were broker-based, agent-based, token-based, gateway-based, and agent and broker -based. Each of these has advantages and disadvantages when analyzed from different point-of-view including implementation, administration, security, and usage of the systems.

The model that combines brokers and agents seems to avoid most of the pitfalls of Single Sign-On. With the increasing use of Web-based services, the gateway-type solutions may also prove to be successful. 

References

[1]

This is a view of the security market as seen by the author of the paper

[2]

J. Linn. 1997.  Generic Security Service Application Program Interface, Version 2. ftp://ftp.funet.fi/pub/standards/RFC/rfc2078.txt

[3]

Transarc Corporation. 1996.  Overview of DCE.  http://www.ux1.eiu.edu/~csjay/dce/intro_to_dce_2.html

[4]

Nomen Nescitur. 1995.  OSF Distributed Computing Environment (DCE). http://www.cs.odu.edu/~secure/pmsdocs/overview.html

[5]

Red Hat Software. 1997.  PAM - Pluggable Authentication Modules.  http://www.redhat.com/linux-info/pam

[6]

Nomen Nescitur. 1997.  Kerberos: The Network Authentication Protocol.  http://web.mit.edu/kerberos/www

[7]

Mark Vandenwauver. 1995.  SESAME V3.  http://www.esat.kuleuven.ac.be/cosic/sesame3_2.html

[8]

Nomen Nescitur.  Security in a Distributed Environment.  http://osiris.wu-wien.ac.at/inst/zid/abteil/azi/service/aix/htmlbooks/gg242543.00/2543ch4.html

[9]

DataFellows Ltd. 1997.  SSH Users Administrators Guide, pp. 97-98. Gummerus Printing.

[10]

Security Dynamics Corporation. 1997.  SecurID Tokens Datasheet. http://www.securid.com/solutions/products/tokens.html

[11]

Axent Technologies, Inc. 1997.  Omniguard/ERM.  http://www.axent.com/product/erm/erm2.htm

[12]

Cylink Corporation. 1997.  Cylink PrivateWire. http://www.cylink.com/external/products.nsf/pages/PrivateWire?OpenDocument

[13]

Bruce Schneier. 1996.  Applied Cryptography, 2nd ed., p 572. John Wiley & Sons, Inc.