The objects used in this description of security are
those units of the distributed system that are subject to security,
they are a modeling concept. The reader should not confuse these objects
with those used in a programming environment, or objects used in other
parts of the book. There is a relationship between security objects
and programming objects, but it usually not one-to-one.
In an object-oriented distributed system access control means controlling
the interaction between the objects and providing the objects with
facilities to control access to information within the object. It
is important to realize that just controlling object interaction is
insufficient in many systems since it is not feasible to make the
security objects small enough to represent individual items of information.
For instance, in many current systems a database is treated as a single
object supporting the methods of the database Management System. The
security of the object system cannot be used within the database,
however there is a need to apply access control within a database.
This situation may be avoided by using an object-oriented database.
Before an object can be allowed access to another object the identity
of both objects must be established so that the appropriate access
control rule can applied. The identity of the accessed object is often
taken for granted, since it represents the information or resources
of the system. It is the identity of the accessing object that is
usually in question. The process of establishing the identity of an
object in the system is called authentication. There are two types
of entity in a distributed system that are the subject of security:
the objects (which model all activity within the system) and human
beings. A distributed system is built by humans to be used by humans
for humans. Thus all activity within a system is carried out on behalf
of some human or other. We can consider the objects in a distributed
system as working on behalf of (as a proxy for) a human.
The most easily understood aspect of authentication is that of identifying
humans. The user identity-password technique is a well known
mechanism. The essence of human authentication consists of two or
more steps. First the human must identify itself to the system (the
purpose of the user identity). Then the human and the computer may
exchange one or more secrets. The idea is that only the individual
human and the computer know the secrets - therefore if the correct
secrets are exchanged then this can only be the claimed human. It
is sometimes necessary for the computer to authenticate itself to
the human by providing some secrets; this may be particularly important
where communications links are used by the human to access the computer.
One of the main purposes of authentication is to distinguish the users
of the system for the purpose of accountability. All security activity
in a distributed system will be audited by the system and a log of
the events held in some archival form. This log, sometimes known as
an audit trail, is analyzed to see if the security policy of the system
is being properly implemented. Every action in the system will be
attributed to some user, who will then be held responsible for that
action. Only by correctly identifying users can they be held accountable
for their actions. When humans know that they are accountable they
are usually less inclined to things they shouldn't.
Within the distributed system each object will have two identities
which will be used for security purposes: the identity of the object
itself (i.e. the object identifier, some unique system wide object-identifier),
and the identity of the human on whose behalf the object is currently
working. Some objects will have been designed to interface to humans,
these would handle the man-machine interface and perform the authentication
of individual human users. If an object invokes another object then
the invoked object will be working on behalf of the same human as
the invoking object. In most systems it is the human identity that
an object is currently using that will determine the access privileges
of the object.
The concept of one object invoking another on behalf of a third object
is called <#738#> proxy<#738#>. Every activity of invocation in a system
must begin somewhere, let us call that object the <#739#> principal<#739#>.
The identity and privileges of the principal will be the main ones
for determining what the invoked objects may do. For the purposes
of an example let us call the principal object A. A calls object B
to carry out some function for it. To complete this function B calls
object C. When B calls C, B is acting as a proxy for A. If it is necessary
for object C to invoke a further object then C will also be acting
as a proxy for A, but also as a proxy for B.
Objects in the system will be authenticated when they are created
by the object infrastructure. The allocation of a unique object identifier
and the placing of the object within the infrastructure is effectively
all the authentication an object needs. The question of how the infrastructure
is authenticated, and who authenticates the entity that authenticates
the infrastructure is an important problem in the design of actual
systems.
An identity, in a security sense, is usually thought of as a token
of privilege. That is the holder uses the identity to obtain privileges
(access rights) which allow a human user to obtain real work from
the distributed system. On the other side an identity should also
be seen as a token of responsibility which is used by the system to
track operations on objects and consequently the activity of a human
within the system. Identities are used for three major purposes in
a distributed system:
-
Access control.
This is the use of the identity to obtain privileges within the system.
-
Audit.
This identity is used by the system to record the activity of the
owner and establish responsibility.
-
Charging.
This identity will be used to accumulate charges for resources used
within the distributed system.
These three identities do not have to be the same, a different identity
may be required for each use. Each identity will require a level of
granularity, that level will be set by the security and charging policy
of the actual system. For instance, the charging policy may determine
that all charges are accumulated on a department basis. This would
mean that everyone in the same department would have the same charging
identity. The same policy may require that each individual needs to
have their actions recorded in the audit; so every person has a different
audit identity. Perhaps the department is responsible for three different
tasks in the distributed system; so only three different sets of privileges
are required to complete these functions; and only three access control
identities are needed. A combination of access control privileges
required for a specific set of related operations are often called
a role. A person using the system would have to indicate to the login
object their name, and their secret which would establish their identity.
They would then need to indicate which role they wanted to take so
they could be allocated the access control privileges for the required
function. Obviously, if the granularity of two types of identity coincide
then they can be served by the same identity value. It is possible
for a system to allow anonymous users whose identity cannot be determined
by any of the objects in the system. In this case a special audit
identity is issued which cannot be traced within the system to any
individual. However, the device which authenticates the anonymous
user produces an audit record containing the actual identity of the
user, and the special audit identity. Then the user can be tracked
only by examining the audit records of the system.