Access Control and Authentication

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:
  1. Access control. This is the use of the identity to obtain privileges within the system.
  2. Audit. This identity is used by the system to record the activity of the owner and establish responsibility.
  3. 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.