Single Sign-On Page 1 sur 15

Single Sign-On
Jani Hursti
Department of Computer Science
Helsinki University of Technology
1997-11-19
Jani.Hursti@hut.fi

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

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 2 sur 15

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.

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 3 sur 15

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.

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 4 sur 15

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.

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 5 sur 15

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

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 6 sur 15

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.

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 7 sur 15

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

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 8 sur 15

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.

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 9 sur 15

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

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 10 sur 15

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.

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 11 sur 15

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.

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 12 sur 15

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

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 13 sur 15

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

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 14 sur 15

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,

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013
Single Sign-On Page 15 sur 15

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.

http://www.tml.tkk.fi/Opinnot/Tik-110.501/1997/single_sign-on.html 27/10/2013