An evolution of DCE authorization services - Open Software Foundation's Distributed Computing Environment specification - Technology Information

Hewlett-Packard Journal, Dec, 1995 by Deborah L. Caswell

One of the strengths of the Open Software Foundation's Distributed Computing Environment is that it allows developers to consider authentication, authorization, privacy, and integrity early in the design of a client/server application. The HP implementation evolves what DCE offers to make it easier for server developers to use.

In the Open Software Foundation's Distributed Computing Environment (DCE),1,2 services are provided by server processes. They are accessed on behalf of users by client processes often residing on a different computer. Servers need a way to ascertain whether or not the user has a right to obtain the service requested. For example, a banking service accessed through an automated teller machine has to have a way to know whether the requester is allowed to withdraw money *om the account. A medical patient record service has to be able to know both who you are and what rights you should have with respect to a patient's record. A policy can be implemented such that only the patient or the legal guardian of the patient can read the record, but doctors and nurses can have read and write access to the record.

The process of determining whether or not a user has permission to perform an operation is called authorization. It is common to separate the authorization policy from the authorization mechanism. Authorization policy dictates who has permission to perform which operations on which objects. The mechanism is the general-purpose code that enforces whatever policy is specified. In DCE, the encoding of the authorization policy is stored in an access control list (ACL). Every object that is managed by a server such as a bank account or a patient record has associated with it an ACL that dictates which clients can invoke each operation deflned for the object.

For example, to encode the policy that the owner of the bank account can deposit and withdraw money from the account and change the mailing address on the account, but only a bank teller may close the account, an ACL on a bank account owned by client Mary might look like:

user:Mary:DWM

group:teller:C where D stands for permission to deposit, W for permission to withdraw, M for permission to change the mailing address, and C for permission to close the account.

Each application is free to define and name its own set of permissions. The D, W, and C permissions used in the example above are not used by every server. An application in which the D (deposit) permission makes sense could choose to name it as the " " permission. Also, many applications will not have a deposit operation at all. Therefore, the interpretation of an ACL depends on the set of permissions defined by the server that uses it.

The first part of this paper describes the specifications and authorization mechanisms (code) offered in DCE that support the development of authorization services. The second part describes our efforts to supplement what DCE offers to make it easier for the server developer to use authorization services. The ACL functionality described here pertains to DCE releases before OSF DCE 1.1 and HP DCE 1.4.

Authorization Based on Access Control Lists

Fig. 1 shows the client/server modules required for an ACL authorization scheme used in a hypothetical bank application that was implemented using DCE. To understand the interactions between these modules consider the following scenario. Jane makes a request to withdraw U.S. $100.00 from her account number 1234. The application interface passes this information to the ACL manager asking for an authorization decision. The ACL manager retrieves the authorization policy for account 1234 from the ACL database and applies the policy to derive an answer. If Jane is authorized, the machine dispenses the money.

When Jane's account is first set up, a bank employee would use an administration tool (from the management process in Fig. 1) to give Jane permission to withdraw money from account 1234. The editing interface enables the ACL manager to change the policy. The ACL manager changes a policy by retrieving the current policy, modifying it, and writing it back to the ACL database.

ACL Database. A server that needs to authorize requests must have a way to store and retrieve the ACLs that describe the access rights to the objects the server manages. One application might want to store ACLs with the objects they protect and another might want a separate ACL database. Depending on the number of objects protected and access patterns, different database implementations would be optimal. For this reason, the requirements for an ACL storage system are likely to be very dependent on the type of application.

An Authorization Decision. When an application client makes a request of the application server, control is given to the manager routine that implements the desired operation. The manager routine needs to know what set of permissions or access rights the client must possess before servicing the request.

The manager routine must supply the client's identity (Jane), the name of the protected object (Account 1234), and the desired permissions (withdraw) to a routine that executes the standard ACL authorization algorithm. If the routine returns a positive result, the server will grant the client's request (dispense U.S. $100). Note that the authorization system depends on the validity of the client's identity. Authentication is a necessary prerequisite for authorization to be meaningful.