Introduction to Single Sign-on

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:

• reduction in the time taken by users in sign-on operations to individual domains, including reducing the possibility of such sign-on operations failing through user error

• improved security through the reduced need for a user to handle and remember multiple sets of authentication information

• reduction in the time taken, and improved response, by system administrators in adding and removing users to the system or modifying their characteristics

• improved security through the enhanced ability of system administrators to maintain the integrity of user account configuration including the ability to inhibit or remove an individual user's access to all system resources in a co-ordinated and consistent manner.

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:

• Directly, the information supplied by the user is passed to a secondary domain as part of a secondary sign-on.

• Indirectly, the information supplied by the user is used to retrieve other user identification and user authentication information stored within the a single sign-on management information base. The retrieved information is then used as the basis for a secondary domain sign-on operation.

• Immediately, to establish a session with a secondary domain as part of the initial session establishment. This implies that application clients are automatically invoked and communications established at the time of the primary sign-on operation.

• Temporarily stored or cached and used at the time a request for the secondary domain services is made by the end-user.

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:

• The secondary domains have to trust the primary domain to:

  • correctly assert the identity and security attributes of the end user

  • protect the authentication information used to verify the end user identity to the secondary domain from unauthorized use.

• The authentication information has to be protected when transferred between the primary and secondary domains against threats arising from interception or eavesdropping leading to possible masquerade attacks.

Scope of XSSO

• the development of applications to provide a common, single end-user interface for an enterprise for sign-on, sign-off and password change operations

• the development of applications for the co-ordinated management of multiple user account management information bases maintained by an enterprise.

Functional Objectives

User Sign-on Interface

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

• The interface shall be independent of the type of authentication information handled and shall be capable of supporting all appropriate sign-on interactive sequences including none. For example, a smartcard may be used to supply a user identity to XSSO for the primary sign-on instead of prompting the user.

• Change of user controlled authentication information shall be supported. This is interpreted as initially being restricted to change of user password although capability for future extension shall not be precluded.

• Support shall be provided for an application calling the sign-on interface to establish a security context based upon a default user profile. User selection of a security context from a set of available user profiles is not required to be supported but shall not be precluded as a future extension.

• On session termination, or sign-off, the initiation of cleanup services that clean up at least the system on which the original sign-on was performed shall be supported.

• XSSO shall not require that all sign-on operations are performed at the same time as the primary sign-on operation. This otherwise would result in the creation of user sessions with all possible services even though those services may not actually be required by the user.

• Support shall be provided for the management of system sign-on policy.

• XSSO APIs must not preclude the use of 16 bit characters, although other system components may preclude their use in particular instances.

• The automatic refresh of credentials used for sign-on operations shall be supported.

• Both administratively controlled and algorithmic mappings between primary and secondary sign-on naming systems shall be supported.

Account Management Interface

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

• The creation, deletion, and modification of accounts shall be supported.

• The setting of attributes for individual accounts shall be supported. The attributes to be supported shall include as a minimum those necessary to support the XBSS.

Non-functional Objectives

• The XSSO shall be authentication technology independent. The interface shall not prescribe the use of a specific authentication technology, nor preclude the use of any appropriate authentication technology.

  Note:

  Some authentication technologies, for example those based upon challenge-response mechanisms of which a user held device is a component may not be appropriate for use as part of secondary sign-on functions without invoking further user interaction.

• XSSO shall be independent of platform or operating system. XSSO shall not preclude the integration of common desktops or common servers, including mainframes. There is no expectation that such desktops or servers shall be capable of integration within XSSO without modification.

• It shall be possible to integrate legacy applications into the XSSO framework, and XSSO shall be designed to facilitate this. It may, however, be necessary for changes to be made to those applications at the level of the source code.

• XSSO shall support sign-on to a client component of legacy client-server systems on both the local and remote platforms.

Security Objectives

• XSSO shall not require the introduction of a single point of failure into a system.

• XSSO shall not adversely impact the availability of any individual system service.

• XSSO shall support the authorization policies enforced by the constituent applications of the policy domain. That is, a principal shall only be able to obtain access via the services of XSSO to the same account information pertaining to an application that the principal is authorized to access using the services of the application itself.

• The XSSO shall not preclude the audit of all security relevant events which occur within the context of the XSSO.

• An XSSO implementation shall protect all security relevant information supplied to or generated by the XSSO implementation such that other services may adequately trust the integrity and origin of all security information provided to them as part of a secondary sign-on operation.

• An XSSO implementation shall provide protection to security relevant information when exchanged between its own constituent components and between those components and other services.

Out of Scope - End-user Sign-on Interface

• Support for single sign-on across policy domain administrative boundaries.

• User initiated change of non-user configurable authentication information, for example magnetic badges, smartcards, and so on.

• Password synchronization between multiple authentication domains.

• Facilities for a user to claim a subset of permitted attributes when signing on or when initiating a secondary sign-on operation.

• Configuration and management of alternative sets of user profiles.

• Boot-time passwords. XSSO only applies to a system with a fully operational operating system.

• Facilities to support a change of user identity associated with an active session.

• Dependency of authentication method upon location or user identity or both. That is, the dynamic specification of the authentication mechanism.

• Multiple namespaces for primary sign-on. The user is not required, nor able, to select the primary domain for which the sign-on name is supplied. This is controlled by the XSSO sign-on configuration.

• Control of the sequence of secondary sign-on operations once the primary sign-on is completed. XSSO only controls the sequence of operations, including secondary sign-ons and credential acquisition, during the primary sign-on operation. Once this is completed the sequence of secondary sign-on operations is under the control of the end-user.

• Facilities for an end-user to configure services into XSSO. The configuration of XSSO is an administrative facility only.

• Maintenance of the consistency of the single sign-on account information base with underlying individual service account information bases when those underlying user account information bases are modified by means other than XSSO provided functionality. It is assumed that all account information bases are managed via the XSSO service.

• Graphical and command line user interfaces to XSSO based services. These are the province of applications written to utilize the XSSO.

• The definition of protocols to support interoperability between components from different XSSO implementations.

Out of Scope - Account Administration Interface

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.