Databases Reference
In-Depth Information
process if they are needed, and thus that any access authorized by the current
set of valid policy statements can be granted.
4.1 General-Purpose Query Evaluation Engine
As mentioned above, PolicyMaker [10] was the first trust management system
per se
. It aimed to provide a general-purpose, application-independent defi-
nition of proof of compliance. The designers identified two main advantages
that can be obtained by using a general-purpose compliance checker. First,
the design and implementation of an authorization system is not as simple as
application programmers might at first imagine, and considerable eciency
can be obtained from reusing a general-purpose authorization engine. Second,
it is a generally accepted design principle to minimize the amount of code
whose integrity is essential to the secure operation of the system. By clearly
separating the role of the application from the role of the compliance checker,
PolicyMaker provides a general-purpose application-independent compliance
checker that can be explained, formalized and proven correct once and for all.
Applications that use PolicyMaker's compliance checker can thus gain high
assurance that compliance-checker results depend only on the given query and
assertions, and not on any implicit policy decisions or bugs in the design or
implementation of the compliance checker. Subsequent TM systems have all
followed PolicyMaker's example in these respects.
4.2 Eciency and Expressivity
In the interest of generality, PolicyMaker [10] put very few restrictions on
the specifications of authorizations and delegations. Policies and credentials
(collectively called
assertions
) are given by arbitrary executable programs.
As long as the underlying programming language is safe in the sense that it
is restricted in terms of the I/O operations and resource consumption per-
mitted, there are no restrictions on what programming language is used. The
advantage of this is that it is clearly flexible and expressive enough to allow
application developers to define authorizations and their delegations however
they wish. However, there are also serious shortcomings, including that com-
pliance checking is in general undecidable. No algorithm can, for each set of
assertions and each request, decide whether the request is authorized.
PolicyMaker evaluation proceeds by iteratively selecting an assertion and
executing it. Each assertion can output a set of “acceptance records” as inter-
mediate results. These are added onto a global append-only
blackboard
.The
contents of the blackboard are available to be read by assertions executed sub-
sequently. It is not defined in what order or how many times the assertions
should be run by the compliance checker. However, a proof of compliance is
given by a (possibly repeating and non-exhaustive) sequence of assertions that,
when run by the compliance checker, leaves on the blackboard an acceptance
record indicating that the request is approved.
