Check out the new USENIX Web site. next up previous
Next: CRISIS Protocols Up: System Architecture Previous: Time

Authorization

Once a request has been securely transmitted across the wide area, and properly authenticated, the remaining task is authorization, determining whether the principal making the request should be granted access. Traditionally, both Access Control Lists (ACLs) and capabilities have been used to describe the set of principals authorized to access a particular object. Since both ACLs and capabilities have advantages in different situations, we use a hybrid model similar to that proposed in [Neuman 1993].

The targets of CRISIS ACLs are service-specific. Currently, file ACLs contain lists of principal's authorized for read, write, or execute access to a particular file. Process execution ACLs are a simple list describing all principals permitted to run jobs on a given node. CA ACLs contains the list of principals authorized to update, modify, or revoke identity certificates.

A process requests access to an object by contacting the object's reference monitor. In CRISIS, reference monitors are implemented on a service-by-service (e.g., file service) basis and form separate modules in the security manager. For example, the WebFS reference monitor is a separate module in the CRISIS security manager.

CRISIS takes a push-based approach to providing credentials for authorization: requesters are responsible for proving they are authorized to access to an object. Thus, principals transmit to reference monitors their request in conjunction with a list of certificates describing their credentials. This list of certificates may simply contain the requester's identity certificate or may contain a more elaborate set of transfer certificates. The alternative to push, a pull-based mechanism where the reference monitor requests necessary credentials from principals, can provide more flexibility; however, it also complicates system design and can reduce performance.

To determine whether a request for a particular operation should be authorized, the reference monitor first verifies that all certificates are signed by a public key with a current endorsement from a trusted CA and OLA. In doing so, the reference monitor checks for a path of trust between its home domain and the domains of all signing principals (as described in Section 4.3). In the common case, the existence of such paths is cached. The reference monitor then checks that none of the timeouts have expired and that time is reported relative to a value stated by a trusted time server (again by checking for a path of trust to the time server).

Once the above steps are taken, the reference monitor is ensured that all certificates are well-formed and valid. Given this knowledge, the reference monitor then reduces all certificates to the identity of single principals. For transfer certificates, this is accomplished by working back through a chain of transfers to the original granting principal. The requesting principal is able to act on the behalf of the reduced list of principals. Finally, the reference monitor checks the reduced list of principals against the contents of the object's ACL, granting authorization if a match is found.


next up previous
Next: CRISIS Protocols Up: System Architecture Previous: Time
Amin Vahdat
12/10/1997