Previous section.

X/Open Single Sign-on Service (XSSO) -<br> Pluggable Authentication Modules

X/Open Single Sign-on Service (XSSO) -
Pluggable Authentication Modules
Copyright © 1997 The Open Group

Introduction to Single Sign-on

As IT systems proliferate to support business processes, users and system administrators are faced with an increasingly complicated interface to accomplish their job functions. Users typically have to sign-on to multiple systems, necessitating an equivalent number of sign-on dialogues, each of which may involve different usernames and authentication information. System administrators are faced with managing user accounts within each of the multiple systems to be accessed in a co-ordinated manner in order to maintain the integrity of security policy enforcement. This legacy approach to user sign-on to multiple systems is illustrated in Legacy Approach to User Sign-on to Multiple Systems .
Figure: Legacy Approach to User Sign-on to Multiple Systems

Historically a distributed system has been assembled from components that act as independent security domains. These components comprise individual platforms with associated operating systems and applications.

These components act as independent domains in the sense that an end-user has to identify and authenticate himself independently to each of the domains with which he wishes to interact. This scenario is illustrated in Legacy Approach to User Sign-on to Multiple Systems .

The end user interacts initially with a Primary Domain to establish a session with that primary domain. This is termed the Primary Domain Sign-on in Legacy Approach to User Sign-on to Multiple Systems and requires the end user to supply a set of user authentication information applicable to the primary domain, for example a username and password. The primary domain session is typically represented by an operating system session shell executed on the end user's workstation within an environment representative of the end user (for example, process attributes, environment variables and home directory). From this primary domain session shell the user is able to invoke the services of the other domains, such as platforms or applications.

To invoke the services of a secondary domain an end user is required to perform a Secondary Domain Sign-on. This requires the end user to supply a further set of user authentication information applicable to that secondary domain. An end user has to conduct a separate sign-on dialogue with each secondary domain that the end user requires to use.

From the management perspective the legacy approach requires independent management of each domain and the use of multiple user account management interfaces.

Considerations of both usability and security give rise to a need to co-ordinate and where possible integrate user sign-on functions and user account management functions for the multitude of different domains now found within an enterprise. A service that provides such co-ordination and integration can provide real cost benefits to an enterprise through:

Figure: Single User Sign-on to Multiple Services

Such a service has been termed Single Sign-on after the end-user perception of the impact of this service. However, it is not intended to preclude prompting a user for additional information if it is required. An alternative appropriate term that could be used is Integrated Sign-on. In addition, both the end-user and management aspects of the service are equally important.

The Single Sign-on approach is illustrated in Single User Sign-on to Multiple Services . In the single sign-on approach the system may collect from the user as, part of the primary sign-on, all the identification and user authentication information necessary to support the authentication of the user to each of the secondary domains that the user may potentially require to interact with. The information supplied by the user is then used by Single Sign-on Services within the primary domain to support the authentication of the end user to each of the secondary domains with which the user actually requests to interact.

The information supplied by the end-user as part of the Primary Domain Sign-on procedure may be used in support of secondary domain sign-on in several ways:

From a management perspective the single sign-on model provides a single user account management interface through which all the component domains may be managed in a co-ordinated and synchronized manner.

From an integration perspective significant security aspects of the Single Sign-on model are:

Scope of XSSO

The scope of the XSSO is application program interfaces in support of:

Functional Objectives

User Sign-on Interface

The following functional objectives have been defined for the XSSO in support of a user sign-on interface:

Account Management Interface

The following functional objectives have been defined for the XSSO in support of an account management interface:

Non-functional Objectives

The non-functional objectives of the XSSO are:

Security Objectives

The security objectives to be met by the XSSO are:

Out of Scope - End-user Sign-on Interface

The following aspects are not considered to be within the current scope of XSSO:

Out of Scope - Account Administration Interface

The specification of an interface and protocols to support the co-ordinated management of multiple account management information bases is deferred to a future specification.

These services are included in the description of the architecture. See XSSO Architecture for contextual information. Also, XSSO Account Management Services provides an introduction to the scope of the services to be covered by a future specification for Account Management Interfaces.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index