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 below:
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 system 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 above.
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 the above diagram and requires the end
user to supply a set of user credentials 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 (e.g., process
atrributes, 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 credentials 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. The secondary
domain session is typically represented by an operating system
shell or an application shell, again within an environment
representative of the end user. 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
- 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 access rights.
- 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.
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, both the end-user and management aspects of the
service are equally important. This approach is illustrated in the
diagram above. In the single sign-on approach the system is
required to collect from the user as, part of the primary sign-on,
all the identification and user credential 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 credential 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 coordinated and synchronized manner.
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 authentication credentials of the end user,
- protect the authentication
credentials used to verify the end user identity to the
secondary domain from unauthorized use.
- The authentication credentials
have to be protected when transferred between the primary and
secondary domains against threats arising from interception or
eavesdropping leading to possible masquerade attacks.
|
