There has been other recent work on access control models for Internet user agents [7], [8]. These models are restricted to using the Javakey utility as an authentication mechanism based on public key digital signatures, while our model is general enough to use a variety of security mechanisms based on public or secret key cryptosystems. Also, our model is application-independent whereas the models in [7] and [8] are targeted specifically at browser-like applications.
The Generalized Access Control List (GACL) framework described by Woo and Lam [3] presents a language-based approach for specifying authorization policies. The main goal of the GACL framework is merging policies associated with different objects with complex dependencies. GACL allows specification of the inheritance rules; access rights can be propagated from one object to the other. A gacl may reference other gacl in its entries. The benefit of this scheme is the ability to omit redundant information at the cost of of retrieval and evaluation of more then one gacl. Specification of policy dependencies with inheritance is error-prone and may result in circular dependency of the policies and inconcistent authorizations. More importantly, the expressive power of GACL is limited to an ACL-based schemes and provides no support for capabilities and multi-level security systems.
The GACL model supports only system state-related conditions within which rights are granted, such as current system load and maximum number of copies of a program to be run concurrently. This may not be sufficient for distributed applications. Our model allows fine-grained control over the conditions.
Policy management issues were addressed by Blaze, et al [9]. The authors claim that a system using the PolicyMaker has strengthened security because the PolicyMaker credentials bind granted rights to public keys, rather then identities, thus eliminating one level of indirection. This is not the case if the system uses X.509 or PGP certificates, the most widely used certificates, because the application is responsible for translating them to the PolicyMaker format.
Policies in the PolicyMaker format can be easily expressed in our framework. We think about security policies as a set of operations that subjects are allowed to perform on the targeted objects, and optional constraints are placed on the granted operations. The purpose of access control is to protect objects from unauthorized access. The basic question is whether this subject is allowed to perform the requested operation. The GAA API provides a common interface for asking this question and it is as simple as setting an appropriate bit.
In contrast, to use PolicyMaker an application developer must define an application-specific language describing the requested operation. The language may not be reusable across different application domains and it forces developers to reinvent the weel.
Both policy evaluation mechanisms, GACL and PolicyMaker, are static. Decisions are based on a set of policies and credentials presented at the time of the request. In contrast, our framework allows dynamic policy evaluation. Additional credentials can be obtained during recursive evaluation within the GAA API.