Cassandra: Distributed Access Control Policies with Tunable Expressiveness

Moritz Y. Becker Peter SewellComputer Laboratory, University of CambridgeJJ Thomson Avenue, Cambridge, United Kingdom

{moritz.becker, peter.sewell}@cl.cam.ac.uk

Abstract

We study the specification of access control policy inlarge-scale distributed systems. Our work on real-worldpolicies has shown that standard policy idioms such as rolehierarchy or role delegation occur in practice in many sub-tle variants. A policy specification language should there-fore be able to express this variety of features smoothly,rather than add them as specific features in an ad hoc way,as is the case in many existing languages.We present Cassandra, a role-based trust management

system with an elegant and readable policy specificationlanguage based on Datalog with constraints. The expres-siveness (and computational complexity) of the languagecan be adjusted by choosing an appropriate constraint do-main. With just five special predicates, we can easily ex-press a wide range of policies including role hierarchy,role delegation, separation of duties, cascading revoca-tion, automatic credential discovery and trust negotiation.Cassandra has a formal semantics for query evaluation andfor the access control enforcement engine. We use a goal-oriented distributed policy evaluation algorithm that is ef-ficient and guarantees termination. Initial performance re-sults for our prototype implementation have been promis-ing.

1. Introduction

The emergence of wide-area network-based servicesposes new and challenging problems to security manage-ment. The networks in question are generally heteroge-neous, decentralised and large-scale, with possibly millionsof autonomous entities (which may be individuals, agents,organisations or other administrative domains) that wish toshare their resources in a secure and controlled fashion.Collaborating entities may be mutual strangers at first, thusaccess control cannot be based on identity, as it is the casein traditional approaches.In the trust management approach [5], authorisation is

based on credentials, digitally signed certificates asserting

attributes about entities holding them. In systems support-ing trust negotiation [19], peers establish trust betweeneach other by exchanging sets of suitable credentials. Apolicy specification language is used to define a system’ssecurity policy, a set of rules specifying the security goalsin a high-level language. This approach separates pol-icy from implementation, simplifies security administrationand facilitates policy evolution.The diversity of emerging applications with widely dif-

fering security requirements has led to the development of avariety of increasingly expressive policy specification lan-guages (e.g. [5, 6, 9, 11, 14, 13, 12, 7]). Existing ones areextended to accommodate more complex policies. For ex-ample, the role-based trust management languageRT0 [14]was extended to RT1 to handle parameterised roles, andto RTT to express separation of duties [13]. Another ex-tension of RT , RT C

1 [12], provides constructs for limitingthe range of role parameters using constraints. However,adding constructs to a language in an ad hoc fashion to in-crease its expressiveness has several disadvantages. Firstly,it is unlikely that the extension will cover all policies of in-terest; secondly, the semantics and implementations of thelanguage have to be changed; thirdly, languages with manyconstructs are harder to understand and to reason about;and lastly, policy evaluation usually becomes computa-tionally more expensive with increasing expressiveness (insome cases, the language is even Turing-complete).We have designed a trust management system,

Cassandra, in which the expressiveness of the policy speci-fication language can be adjusted by selecting an appropri-ate constraint domain. The advantage of this approach isthat the expressiveness (and hence the computational com-plexity) can be chosen depending on the requirements ofthe application, and can easily be changed without havingto change the language semantics. In our prototype imple-mentation of Cassandra, a constraint domain is a separatemodule that can be plugged into the policy evaluation en-gine. We have identified a condition on constraint domains,constraint compactness, which ensures that policy evalua-tion is decidable and guaranteed to terminate.By factoring out the constraint domain, the language

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE

perform action

deactivate role

activate role

request credential

Inte

rfac

e

Policy(rules & credentials)

Acc

ess

Co

ntr

olE

ng

ine Policy

Evaluatorinvoke

modify

grant access

query

Cassandra Entity remote query

Resources(Actions)

C

Figure 1. Cassandra components.

syntax and semantics are kept small and simple. In par-ticular, Cassandra has no explicit provisions for standardpolicy idioms such as role hierarchy, separation of dutiesor delegation; instead, it is truly policy-neutral in that itcan encode such idioms (and many variants). Its expres-siveness suffices for policies found in highly complex real-world applications; this has been shown by our work on alarge-scale security policy for a national electronic healthrecord system [3].In §2 we give an informal overview of Cassandra’s pol-

icy specification language. Unlike most other systems,Cassandra not only formally specifies the policy languagebut also the access control semantics governing the dy-namic behaviour of an entire Cassandra network. Thisoperational semantics is described in §3. §4 shows howexamples of standard policies, including role validity peri-ods, role hierarchy, separation of duties, role delegation andtrust negotiation policies, can be expressed in Cassandra.The policy specification language and semantics are for-mally defined and an algorithm for policy evaluation isgiven in §5. §6 briefly discusses our case study on secu-rity policies for a national electronic health record system.We also discuss our prototype implementation and prelim-inary experimental results. Finally we discuss related workand conclude.

2. Policy specification overview

Cassandra is a trust management system allowing a po-tentially large network of entities to share their resourcesunder well-defined restrictions, specified by local accesscontrol policies, even if they are mutual strangers. Everyentity runs its own copy of a Cassandra service, whichacts as a protective layer around the resources. Figure 1shows the internal components of a Cassandra service. In-teraction with other entities is done via the interface thatdefines requests for performing an action (i.e. accessing aresource), activating and deactivating a role, and request-

ing a credential that can be used to support another requestsomewhere else. The access control engine handles the re-quest by invoking the policy evaluation engine, which inturn queries the local Cassandra policy. The expressive-ness of the policy specification language depends on theglobally chosen constraint domain, C, an independent mod-ule that is plugged into the policy evaluation engine. Aspolicies can refer to policies of other entities, policy eval-uation may trigger queries of remote policies (possibly therequester’s) over the network. The answer of the policyevaluation engine is used by the access control engine todecide whether the request is to be granted. As a result ofa request, the local policy may be modified. For example,if a role is activated, this new fact is put into the policy;similarly, deactivation of roles causes facts to be removedfrom the policy.

Cassandra’s policy specification language is based onDatalogC , a generic extension of negation-free Datalog(Prolog without function symbols) where the expressive-ness can be tuned by varying the constraint domain param-eter C [10]. A DatalogC rule is of the form

p0(�e0) ← p1(�e1), .., pn(�en), cwhere the pi are predicate names and the �ei are (possi-bly empty) expression tuples (that may contain variables)matching the parameter types of the predicate. p0(�e0) isthe head of the rule, and the sequence of predicates on theright hand side of the arrow is the body of the rule; c is aconstraint on the parameters occuring in the rest of the rule.Intuitively, to deduce the head of a rule, all body predicatesmust be deducable in such a way that the constraint is alsosatisfied. A set of DatalogC rules can then be interpreted asthe deductive closure of the set.The constraint of a rule, c, is a formula from some fixed

constraint domain C, a language of first order formulaecontaining at least true, false and the identity predicate“=” between C-expressions (variables, entities and possiblyother constructs). It must be closed under variable renam-ing, conjunction (∧) and disjunction (∨). Furthermore, itmust be equipped with an interpretation that defines whenformulae are satisfied.The expressiveness of DatalogC depends on the chosen

constraint domain C. For example, the least expressive con-straint domain is the one where the only atomic constraintsare equalities between variables and constants. Choosingthis trivial constraint domain reduces the expressiveness ofthe language to standard Datalog or Horn clauses withoutfunction symbols. More powerful constraint domains ofteninclude boolean, arithmetic and set constraints, and makeuse of more complex expressions such as tuples, set expres-sions and (side-effect free) function applications (e.g. to ac-cess the current time). The computational complexity ofevaluating DatalogC programs increases with expressive-ness: with set constraints it is already possible to encode

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE

the Hamiltonian cycle problem, and thus all NP-completeproblems. Care must be taken not to choose a constraintdomain that is too expressive as this can result in programsin which queries are undecidable. We will later introducethe notion of constraint compactness to restrict constraintdomains to those that guarantee termination of queries.In Cassandra, access control is role-based, and roles, as

well as actions, are parameterised. Role-based access con-trol (RBAC) [17, 8] was initially introduced to simplify se-curity administration of large enterprises. In the context ofdistributed trust management, roles can more generally beused as a representation of authenticated subject attributesin decentralised access control [13]. Formally, a role is atyped role name applied to an expression (that may con-tain variables) of a matching type, e.g. Manager(Sales-dept). Similarly, an action is an action name applied to anexpression, e.g. Read-file(file). For the remainder of thepaper, variables will be written in small letters and italics(e.g. file), generic constants in italics but capitalised (e.g.some entity E), and concrete constants in typewriter font(e.g. Sales-dept).Policies are specified by rules defining predicates that

govern access control decisions: permits defines who canperform which action; canActivate specifies who can acti-vate which roles (and thus implicitly defines the role mem-bership relation); hasActivated specifies who is currentlyactive in which role; canDeactivate specifies who can re-voke which role; isDeactivated is used to define automat-ically triggered role revocation; and finally, canReqCredrules specify the conditions to be satisfied before the ser-vice is willing to issue and disclose a credential. User-defined auxiliary predicates are also allowed.In the trust management approach, access control de-

cisions are based on credentials asserting properties aboutthe holders. In Cassandra, the properties asserted by cre-dentials are (constrained) predicates. Therefore, in orderto satisfy a predicate in a rule body, either the predicatecan be deduced from the local policy or it is asserted bya foreign credential issued and signed by some other en-tity. Such credentials are either already stored locally, orare submitted to the service, or automatically fetched by theservice from some other entity. To put constraints on the is-suer and the storage location of credentials, each Cassandrapredicate has an issuer and a location (constant or vari-able) parameter, and is written loc@iss.p(�e). For example,Alice@UCam.canActivate(Alice,Student(Maths)) is apredicate asserting that Alice is a Maths student. If thispredicate is part of a rule body, Cassandra can contact Al-ice over the network (unless this is Alice’s local policy) andrequest the corresponding credential issued by the Univer-sity of Cambridge.We will often write iss.p(�e) as shorthand for

E@iss.p(�e) and p(�e) for E@E.p(�e), if E is clear from the

context. Intuitively, if a predicate loc@iss.p(�e) appears inthe body of a rule in E’s policy, and loc is equal to E,it is deduced locally from E’s policy (if iss is not equalto E, this must be a foreign credential). If, however, locis not equal to E, this means that the authority over thepredicate is delegated to the remote entity loc, so E re-quests a credential iss.p(�e) from loc over the network. locwill allow this only if her local policy lets her deduce bothcanReqCred(E, iss.p(�e)) and iss.p(�e). If these conditionsare met, a credential containing iss.p(�e) (issued and signedby iss) is sent back to E. A more formal treatment of thelanguage semantics is given in §5.1.

3. Access Control Semantics

Cassandra acts as a protective layer around the sharedresources, allowing network access only through an inter-face. This interface defines requests for performing an ac-tion, activating a role, deactivating a role, and for request-ing a credential. Incoming requests are checked by the ac-cess control engine against the local policy (Figure 1). En-tities can support their requests by submitting credentialsto the service; the service will then use the assertions in thecredentials along with its own local policy to evaluate thequery. Granting a request can have side-effects on policies,e.g. when a role is activated, a corresponding hasActivatedcredential rule is added to the policy.We have formally specified the operational semantics of

the access control engine by a labelled transition systemwhere the labels are the requests and the transitions are be-tween sets of policies of all entities. Due to lack of space,we will only give a brief overview of the request defini-tions.

Performing an action. Suppose the requester E at-tempts to perform the (parameterised) action A on S’sCassandra service. E’s request is granted if permits(E,A)is deducible from S’s policy (and submitted credentials).

Role activation. Suppose E attempts to activate the (pa-rameterised) role R on S’s Cassandra service. The requestis granted if the role has not already been activated and ifcanActivate(E,R) can be deduced from S’s policy (andsubmitted credentials). As a result of this transition, thecorresponding hasActivated credential rule is added to S’spolicy.

Role deactivation. Suppose E requests to deactivateV ’s role R on S’s Cassandra service. The request isgranted if V is really currently active in the role R andif canDeactivate(E, V,R) is deducible from S’s policy(and submitted credentials). Depending on the local policyrules, this deactivation may also trigger the deactivation ofother role activations in S’s policy (local cascading deacti-vation). For this purpose, we need to compute the set of all

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE

hasActivated credential rules in S’s policy for which a cor-responding isDeactivated credential can be derived underthe assumption isDeactivated(V,R). The role activationsin this set are then removed from S’s policy.

Requesting Credentials. Suppose E requests the cre-dential I.p(�x) ← c (a digital certificate asserting p(�x) ← c,issued and signed by I) from S. S’s service first computesthe answer to the query canReqCred(E, I.p(�x)) ← c. Theanswer is a constraint c0 restricting the values that �x cantake.If I and S are identical, the answer c1 of the query

p(�x) ← c0 is computed, and, if c1 is satisfiable, the newcredential S.p(�x) ← c1 is issued and sent to E. If I andS are different, this means that the requested credential is aforeign credential held by S, so it cannot be freshly issuedand signed. In this case, S sends E all her credentials ofthe form I.p(�x) ← c2 such that c2 is at least as restrictiveas c0.

4. Standard policies

Unlike other policy specification languages, Cassandradoes not have special constructs for expressing standardpolicies such as role hierarchies, separation of duties ordelegation. Indeed, we can show that Cassandra, equippedwith a sufficiently powerful constraint domain, can expressthese policies in a concise and readable way. Having noconstructs in the language for specific policy idioms notonly keeps the language and its semantics small and sim-ple; it also avoids the necessity of having to constantlyextend the language. Furthermore, our work on policiesfor a national electronic health record infrastructure hasshown that, in large-scale real-world applications, these“standard” policies occur in many variants and combina-tions with subtle but significant semantic differences [3].Cassandrawas designed in such a way that the whole rangeof policy variants can be expressed without additional fea-tures. It should be noted that Cassandra was designedspecifically for authorisation policies; in particular, we donot deal with obligation policies specifying the automatictriggering of actions (as in [7]).In the following, we show how standard policies can be

written in Cassandra.

Role validity periods. In the following rule, a certifieddoctor (with certification issued at time t) is also memberof the role Doc() if t is at most one year ago. This is anexample where the freshness requirement of a certificationis set by the acceptor, not by the certificate issuer (as rec-ommended in [16]). The chosen constraint domain mustcontain a (side-effect free) built-in function that returns thecurrent time, and integer order constraints.

canActivate(x,Doc()) ←canActivate(x,CertDoc(t)),CurTime() − Years(1) ≤ t ≤ CurTime()

Auxiliary roles. Sometimes a role is used solely to ex-press some property about its members and can be usedwithout prior activation. In this rule, a logged-in user canread a file provided that the system can deduce she is theowner of that file. Ownership is here expressed with theauxiliary Owner role that need not be activated.

permits(x,Read(file)) ←hasActivated(x,Login()),canActivate(x,Owner(file))

Role hierarchy. In this variant of parameterised role hi-erarchy, members of a superior role (Engineer workingin some department) are automatically also members of amore basic role (Employee working in the same depart-ment).

canActivate(x,Employee(dep)) ←canActivate(x,Engineer(dep))

Separation of duties. In this common example for sepa-ration of duties, a payment transaction requires two phases,initiation and authorisation, which have to be executedby two different people. The rule implements the dy-namic and parameterised variant of separation of duties: anAuthoriser of a payment must not have activated theInit role for the same payment. This restriction is imple-mented by the user-defined countInitiators predicate. Itsdefinition is given by the second rule, an example of an ag-gregate rule. The count〈z〉 aggregate operator counts howmany different values of z satisfy the body. Therefore, theparameter n is 0 only if x has not activated the Init rolefor the same payment.

canActivate(x,Authoriser(payment)) ←countInitiators(n, x, payment), n = 0

countInitiators(count〈z〉, x, payment) ←hasActivated(z,Init(payment)), z = x

Role delegation. Here, an administrator can delegate herrole to somebody else by activating the DelegateAdmrole for the delegatee. The delegatee can then subsequentlyactivate the administrator role. The first parameter of theadministrator role specifies who the delegator was. Thesecond parameter n is an integer for restricting the length ofthe delegation chain: the delegatee can activate the admin-istrator role only with a “rank” n′ that is strictly less thanthe delegator’s rank n but must be at least 0. Setting theparameter to 1 for non-delegated administrators (i.e. thoseat the top of a delegation chain) amounts to non-transitivedelegation. Removing the constraint on n in the secondrule results in unbounded delegation chains.

canActivate(x,DelegateAdm(y, n)) ←hasActivated(x,Adm(z, n))

canActivate(y,Adm(x, n′)) ←hasActivated(x,DelegateAdm(y, n)), 0 ≤ n′ < n

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE

With the following rule, the delegated role is automaticallyrevoked if the delegation role of the delegator is deacti-vated.

isDeactivated(y,Adm(x, n′)) ←isDeactivated(x,DelegateAdm(y, n))

However, we need to specify who is allowed to deactivatea delegation role. In grant-dependent revocation (first rulebelow), only the delegator herself has this power. In grant-independent revocation (second rule below), every admin-istrator (who has at least as high a rank as the delegator)can deactivate the delegation.

canDeactivate(x, z,DelegateAdm(y, n)) ← x = zcanDeactivate(x, z,DelegateAdm(y, n)) ←

hasActivated(x,Adm(w, n′)), n ≤ n′

A rather paranoid policy may specify cascading revocation:if a delegated administrator is revoked from her role, all herdelegation must also be revoked recursively.

isDeactivated(x,DelegateAdm(y, n)) ←isDeactivated(z,DelegateAdm(x, n′))

The trust management system Oasis [21] has a languageconstruct for role appointment, a generalisation of role del-egation. Our work on real-world policies suggests that vari-ants of general appointment are indeed far more frequentthan role delegation [3]. Appointment and other statefulpolicies can be expressed in Cassandra in a very similarway as shown above for delegation.Automatic trust negotiation & credential discovery.Suppose the following rule is part of the policy of a serverholding the electronic health records (EHR) for some partof the UK’s population. To activate the doctor role, x mustbe a certified doctor in some health organisation org, andfurthermore the organisation must be a certified health or-ganisation. Both requirements must be satisfied in the formof credentials signed by some entity auth belonging to alocally defined set of registration authorities.

canActivate(x,Doc(org)) ←auth.canActivate(x,CertDoc(org)),org@auth.canActivate(org,CertHealthOrg()),auth ∈ RegAuthorities()

In the rule above, there is no location prefix in front of thefirst body predicate, so the doctor certification credentialis required to already be in the local policy or have beensubmitted by x together with the role activation request.No automatic credential requests are issued the credentialis not found. On the other hand, there is a location prefixorg in front of the second body predicate: the health organ-isation credential is automatically requested from org, or,more precisely, the entity the variable org stands for duringactual evaluation. However, the health organisation (say,Addenbrooke’s Hospital) will allow this retrieval requestonly if its canReqCred policy allows it. With the follow-ing rule, Addenbrooke’s specifies that it is willing to reveal

its CertHealthOrg credential, signed by the registrationauthority of East England, to certified EHR servers.

canReqCred(x, y.canActivate(z,CertHealthOrg()) ←x@auth.canActivate(x,CertEHRServ()),y = RegAuthEastEngland ∧ z = Addenbrookes,auth ∈ RegAuthorities()

The x@auth prefix specifies that the required credentialmust be signed by some registration authority and that it isto be retrieved automatically from x; in this case, x willhave been instantiated to be the EHR server. The EHRserver will in turn have canReqCred policy rules specifyingto whom its CertEHRServ credential may be disclosed.As this example shows, a simple request can trigger mul-tiple phases of credential exchanges between two or moreentities over the network until a sufficient level of mutualtrust has been established.

5. Language semantics and evaluation

This section defines the syntax and semantics ofCassandra’s policy specification language. We also de-scribe a goal-oriented algorithm for evaluating policyqueries that is sound and complete with respect to the lan-guage, and discuss a condition for guaranteed terminationof query evaluation.

5.1. Language Semantics

Each entity Eloc on the network protects its resourceswith a (possibly empty) Cassandra policy, a finite set ofCassandra policy rules of the form

Eloc@Eiss.p0(�e0) ←loc1@iss1.p1(�e1), .., locn@issn.pn(�en), c.

The location and the issuer of the rule, Eloc and Eiss, areentity constants, and the loci and issi are entities or entitytyped variables. The pi(�ei) are well-typed predicates, and cis a constraint from the globally chosen constraint domainC.A rule with empty body of the form

Eloc@Eiss.p0(�e0) ← c

is called a credential rule or just a credential. (These cor-respond to facts in Logic Programming.) If it is sent overthe network, it can be thought of as a certificate assertingp0(�e0), signed and issued by Eiss, and belonging to andstored atEloc. The location and the issuer of a rule are usu-ally identical; only in the case of a credential rule can theybe different, as Eloc may hold a foreign credential signedby a different entity Eiss.

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE

Wewill omit the prefixEloc from a rule if it is clear fromthe context, and also Eiss, loci and issi if they are equal toEloc.Access control decisions are based on policy

queries which have the same form as credentials:Eloc@Eiss.p0(�e0) ← c. The answer to a query is a setof constraints ci such that Eiss.p0(�e0) ← c ∧ ci can bededuced from Eloc’s policy. For example, the query

UCam@UCam.canActivate(x,Student(subj)) ←subj = Maths

may return the constraints {x = Alice, x = Bob}, andthe query

UCam@UCam.canActivate(x,Student(subj)) ←x = Alice ∧ subj = Maths

would simply return {true}.The semantics of a policy is defined by the set of all cre-

dentials that can be deduced from it. To formally define thenotion of deduction, we extend the notion of consequenceoperator known from constraint logic programming [18].We construct a consequence operator TP , where P is thefinite union of the policies of all entities. Given a set ofcredentials I (which we distinguish only up to variable re-naming), TP(I) returns the set of all credentials that canbe deduced from I and the policies in P in one step.The definition of TP assumes the existence of two com-

putable operations on C-constraints, ∃C and ⇒C . ∃Cx. (c)computes the existential quantifier elimination of x and re-turns the set of conjuncts in the disjunctive normal form(DNF) of the result. If V is a set of variables, we also write∃C−V (c) for the set of conjuncts in the DNF of c, with allfree variables apart from the ones in V existentially elimi-nated. (This is in effect a projection of c onto the variablesV .)

⇒C is a computable subsumption relation on C-constraints: if c1 ⇒C c2 returns true then c1 is subsumedby c2, i.e. all substitutions that satisfy c1 also satisfy c2.Then the consequence operator TP(I) is defined to con-

tain all credentials of the form Eloc@Eiss.p(�x) ← c0 (forsome entities Eloc, Eiss) if I contains no other credentialthat already subsumes it: if Eloc@Eiss.p(�x) ← c′0 ∈ I andc0 ⇒C c′0 then c0 = c′0; and furthermore, if there is somematching rule

Eloc@Eiss.p(�x) ← P1, .., Pn, c

inP (i.e. in the policy ofEloc) such that there is a constraintc0 with the following property:

c0 ∈ ∃C−�x(c1 ∧ .. ∧ cn), and c0 is satisfiable, for someconstraints c1, .., cn, such that each ci is a contribution fromPi. We say ci is a contribution from Pi ≡ yloc@yiss.q(�y)if one of the following two cases hold.Either yloc is taken to be local, so Pi has to be deduced

from Eloc’s own local policy. This means that ci must be

equal to some(c′i ∧ yloc=Eloc ∧ yiss=E′

iss)such that Eloc@E′

iss.q(�y) ← c′i is already in I.Alternatively, yloc may refer to some remote entity

E′loc = Eloc, so Pi has to be deduced from E′

loc’s policy.As this amounts to a credential request and E ′

loc’s creden-tials are protected by canReqCred rules, the correspondingcanReqCred predicate must also be satisfied, as well as Pi

itself. In this case, ci is some constraint in∃Cxe. (c′i ∧ c′′i ∧ yloc=E′

loc ∧yiss=E′

iss ∧ xe=Eloc)such that both credentialsE′

loc@E′loc.canReqCred(xe, yiss.q(�y)) ← c′i and

E′loc@E′

iss.q(�y) ← c′′i are already in I.The consequence operator TP(I) is continuous on the

powerset of credentials and thus has a unique least fixed-point

⋃n≥0 Tn

P (∅) which we call the fixed-point semanticsof P . It coincides with our intuitive notion of deductiveclosure of the policy rules.Sometimes we need to know not only whether a pred-

icate can be satisfied but also how often. For example, itis often necessary to know that nobody has activated a cer-tain role, i.e. the corresponding hasActivated predicate canbe satisfied 0 times. For these purposes, we define ruleswith aggregation operators [15]. (These require the con-straint domain C to contain equalities over set and integerconstants and variables.) A Cassandra aggregation rule isof the form

Eloc@Eloc.p(aggop〈x〉, �y) ← Eloc@iss.q(�x), cwhere the aggregation operator aggop is either group orcount. The predicate q(�x) is required to be one that canbe satisfied with only finitely many different parameters onEloc, and �x must contain x. If the operator is group, thefirst argument of p stands for the finite set of all differentvalues of x such that the rule body can be satisfied. If theoperator is count, it stands for the cardinality of that set.For example,

getSetOfActiveDoctors(group〈x〉, spcty) ←hasActivated(x,Doctor(spcty))

finds the set of all active doctors with specialty spcty.

5.2. Evaluation

Recall that the access control engine makes access con-trol decisions by invoking the policy evaluation engine,which queries the local policy. We now describe the al-gorithms used in the policy evaluation engine.In deductive databases, queries are usually evaluated

against a model that is pre-computed with a bottom-upalgorithm that, starting from basic facts, iteratively addsderived facts until the fixed-point semantics is reached.

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE

This would not be an acceptable evaluation strategy forCassandra: firstly, the constraints may contain (side-effectfree) function calls that depend on the environment, for ex-ample for getting the current time, and therefore cannot bepre-computed; secondly, the fact that rule bodies can referto remote predicates would require a distributed form ofbottom-up evaluation which would be highly impractical;and thirdly, the model would have to be re-computed afterevery activation or deactivation of roles as role activationand deactivation modify policies.The standard SLD top-down resolution algorithm

known from Logic Programming (e.g. Prolog) is not suit-able either as it may run into infinite loops even when thefixed-point semantics is finite. Instead, Cassandra uses amodified version of Toman’s memoing algorithm for evalu-ating constraint extensions of Datalog [18]. Based on SLGresolution, it combines advantages of both the top-downand the bottom-up approaches: it is goal-oriented and yetpreserves the termination properties of the bottom-up al-gorithms by memoing (tabling) already seen subgoals andtheir answers. To solve a subgoal for which a table en-try already exists, the algorithm uses the tabled answers assolutions; whenever new answers are added for the entry,they are automatically propagated to other waiting evalua-tion branches. If no relevant entry exists for the subgoal, anew table entry is created and populated. We have extendedthe algorithm in [18] to deal with goals referring to remoteentities.Suppose the query Eloc@Eiss.p0(�x0) ← c0 is to be

evaluated by the Cassandra service of Eloc. Evaluation isstarted by calling the Clause Resolution procedure on thequery.

Clause Resolution. Find all policy rules with a matchinghead, i.e. of the form

Eloc@Eiss.p0(�x0) ← P1, .., Pn, c1.For all such c1, compute c2 ≡ c0 ∧ c1 if the result is sat-isfiable. If the rule body is non-empty (n ≥ 1), call theQuery Projection procedure on the list P1, .., Pn, c2. Other-wise call the Answer Projection procedure on the combinedconstraint c2.

Query Projection. This procedure operates on a list ofpredicates P1, .., Pn and a constraint c. Using the ∃C opera-tion, project the constraint onto the free variables of the firstpredicate P1 in the list and compute the DNF constraint set.For all ci from this set, call the Answer Propagation proce-dure on P1 ← ci, and the (possibly empty) list of remainingpredicates, P2, .., Pn.

Answer Propagation. This procedure operates on a sub-goal P ← c, and a list of remaining predicates P2, .., Pn.Check whether we have already encountered a query P ←c′ such that c ⇒C c′, in which case the current goal canbe solved using answers from that query. For each already

existing answer d, combine it with the current constraintand call the Clause Resolution procedure on the remainingpredicates in the list, or the Answer Projection procedure,if the remaining list is empty. We also need to store the in-formation that this query waits for answers from the proofof P ← c′.If, however, no such P ← c′ exists yet, we need

to spawn a new query for P ← c and wait for its an-swers. If the location of P is remote, a credential requestis sent to the remote entity. The remote entity will thencall its Query Projection procedure on the list containingcanReqCred(Eloc, P ) and P with the constraint c.

Answer Projection. This procedure is called when thelist of body predicates is empty. The remaining constraintis then projected onto the free variables of the query pred-icate. The resulting constraints are stored in the answerstable and propagated to all queries currently waiting forsuch answers, and execution is resumed there. If the wait-ing party is a remote entity, the answers are sent to it overthe network in the form of credentials. The remote entitywill then invoke its Answer Projection procedure on theseanswers.

On exit, the table entry for the original query will bepopulated with all its answers. The algorithm is sound andcomplete with respect to the language semantics.As in other database applications, we require query eval-

uation to always terminate. Clearly, if the chosen constraintdomain C is too expressive, it is possible to write poli-cies and queries that are uncomputable. Often, the featuresthat make it too expressive seem rather innocuous at firstglance. For example, constraint domains with untyped tu-ple constructors or with negative gap-order constraints ofthe form x − c < y (where c is a positive integer constant)enable the construction of undecidable policies.Constraint compactness [18] is a sufficient condition on

constraint domains to guarantee a finite and hence com-putable fixed-point semantics for any finite global policyset P . A constraint domain C is said to be constraint com-pact if any infinite set of C-constraints in which only finitelymany variables and constants occur has a finite subset sub-suming the entire set, that is, for every constraint c in theinfinite set there is a constraint c′ in the finite set such thatc ⇒C c′.Unfortunately, constraint compactness severely restricts

the expressiveness of the constraint language and is alsooften hard to prove. We use static groundness analysis [1]to restrict policies in such a way that variables occuring inspecific constructs will always have been grounded (so aunique value can be deduced for each) by the time exis-tential quantifier elimination is performed on them, giventhe query patterns from §3 (e.g. canActivate queries are al-ways fully grounded), so these constructs can be ignored.

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE

We also use static groundness analysis to ensure that thelocation prefix of body predicates becomes ground by thetime we evaluate it: otherwise the evaluator would have toquery many different entities (all, in the worst case), whichis clearly unpractical.

6. Discussion

EHR case study. Cassandra’s design process was par-tially guided by our case study [3] on an access controlpolicy for a national electronic health record (EHR) sys-tem. The background of the case study is the British Na-tional Health Service’s current plan to develop an electronicdata spine that will contain “cradle-to-grave” medical datafor all patients in England. The project is highly risky andchallenging for several reasons: it is extremely large-scalewith 100 million records and billions of accesses per year;the requirements are likely to change frequently, in partic-ular those concerning access control; and it is inherentlydistributed with interacting health organisations, registra-tion authorities and the data-spine. These challenges canbest be met by a distributed trust management system thatallows policies to be specified in a sufficiently expressivehigh-level language.In our case study, we propose a distributed three-level

infrastructure to cope with the large scale. Based on officialspecification documents, we have developed Cassandrapolicies for the entire infrastructure. Our proposed poli-cies contain a total of 310 rules, define 58 parameterisedroles and implement all the required access control rules.The requirements are not only highly complex but also

contain principles unseen in traditional access control mod-els. For example, the policies need to handle explicit pa-tient consent, third-party disclosure consent, individualisedaccess decisions (e.g. a patient could prohibit access torecord items concerning a certain medical subject to a spe-cific doctor), appointment of agents acting on a patient’sbehalf and workgroup-based access control (e.g. based onward or consultant team membership).One of the main lessons learnt from the case study is that

standard policy idioms such as role appointment occur inmany different variants. We thus had to design Cassandrain such a way that it could express all of these elegantly.Our approach was to identify the small number of underly-ing primitives concerning role membership, activation anddeactivation, and to base the language solely on those. Thedistributed nature of the EHR policies also necessitated fea-tures for automatic credential discovery and credential pro-tection (automatic trust negotiation).For the case study, we devised a sufficiently expressive

constraint domain containing tuple expressions and pro-jections, disequalities, integer order inequalities, built-infunctions to access state-dependent data and set inclusion

constraints[3]. It is constraint-compact and thus guaranteesquery termination, but its relatively high expressivenessstill makes it possible in principle to write policies that areprohibitively expensive to evaluate. However, such policiesdo not seem to occur in practice, as the recursion depth isusually small and variables are instantiated to ground val-ues early on.

Implementation and performance. A prototype ofCassandra has been implemented in OCaml. The code isfactored into independent modules as depicted in Figure1. In particular, constraint domain implementations can beplugged into the policy evaluation engine as separate mod-ules, as long as they provide fundamental operations of pro-jection, satisfiability and subsumption checking. We haveimplemented the constraint domain used for the EHR casestudy, including a type inference mechanism that allows usto omit explicit variable typing.At the time of writing, role deactivation and credential

requests and the static groundness analyser are still in theprocess of being implemented. Furthermore, the currentprototype only simulates the distributed system, and issuedcredentials are implemented without encryption and publickey signatures.The prototype was tested with the policies from the EHR

case study. The system behaved as expected and handledall requests, including the most complex ones, within frac-tions of a second. The preliminary results suggest thatCassandra is indeed suitable for large-scale real-world ap-plication. Of course, authoritative results can only be pro-duced after completion of a more complete and optimisedimplementation and under more realistic settings; we havefor example so far only tested the system with up to 10,000patients [3].Our experiments have highlighted another requirement

for policy-based trust management systems that neither ournor existing systems currently fulfil: human users expecttextual justifications of access control decisions, especiallyif their request is denied; they feel rather frustrated andhelpless if the answer is simply “request denied”, espe-cially if the policy is complex or unknown to the user. Suchexplanations could be collected from annotations of policyrules used during deduction. The problem is non-trivial asdeduction proofs can be long and access denials can havemany and far-reaching reasons. More worryingly, the tex-tual justification may reveal more (and perhaps, sensitive)information than could have been deduced from the factof request denial alone: consider, for example, a responsesuch as “access denied because your daughter has prohib-ited you from accessing all her records with the subject‘abortion’ ”.

Related work. A large amount of work has been doneon security policy specification in a non-trust-management

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE

context. For instance, Barker [2] uses constraint logic pro-gramming to encode RBAC policies in a non-distributedenvironment; as such, his approach does not deal with cre-dentials, trust management and trust negotiation. Policy-Maker [5] introduced the trust management paradigm, andits successor, KeyNote [4] defined the first policy specifi-cation language. Since then, many other trust managementsystems have been proposed for policy specification anddistributed access control (e.g. SPKI/SDSI [6], QCM [9],SD3 [11], RT [13], Oasis [21], Ponder[7]).

The Cassandra policy specification language was in-spired by Oasis, a role-based trust management system inwhich Datalog-based rules specify which credentials areprerequisite for role activation and deactivation [21]. Oasishas a special construct for role appointment, which was in-troduced as a useful generalisation of the delegation mech-anisms found in many other languages. Our case study sup-ports the claim that role appointment (and its variants) is avery useful policy idiom. Oasis is the only other systemwe are aware of that supports cascading role revocation. Itsrevocation mechanism works even across the network be-tween collaborating entities. This is implemented using adistributed event infrastructure. Another difference is thatin Oasis, revocation is triggered whenever a specified sub-set of the role activation prerequisites ceases to hold. Incontrast, role deactivations in Cassandra are allowed to betriggered by conditions that have nothing to do with the roleactivation prerequisites. Oasis does not deal with automaticcredential discovery and trust negotiation. It also does notpossess a full formal semantics and does not guarantee ter-mination of queries.

The RT family of role-based trust management lan-guages [13] bears some similarities to our system. In RT,the Datalog-based rules, or credentials, as they are called,specify only the role membership relation: either directly,by role hierarchy, by (direct or attribute-based) delegationof authority, or any combination of these. The subjects ofthe rule head and the body conditions are implicitly thesame, which is sufficient to express delegation but not con-venient for appointment policies. In RT’s youngest off-spring, RT C

1 [12], rules are translated into DatalogC . Con-straints are used only to define a range on each role param-eter; constraints between two parameters are not permittedin order to keep policies more comprehensible and to guar-antee tractability. We find that a more liberal use of con-straints is useful and necessary, as our EHR policy shows,and can still be efficient in practice. RT roles are prefixedwith the issuing entity, just like Cassandra’s predicates are,but do not specify the location where a matching creden-tial may be found. RT solves this by statically specifyingfor each role name whether credentials defining such rolesare stored with the issuer or the subject. Our EHR pol-icy has rules in which predicates have locations different

from both issuer and the subject entity. A distinctive fea-ture of the RT framework is that RT credentials contain alink to a so-called Application Domain Specification Doc-ument (ADSD) that defines a common vocabulary (typesof role parameters, natural language descriptions of rolenames etc.) for collaborating entities.SD3 is another Datalog-based trust management system

[11]. Similar to Cassandra, SD3 predicates can be prefixedwith an issuer (a public key), thereby delegating author-ity of predicate definition to that key. A predicate can fur-ther be tagged with an IP address which is used to refer toa remote policy. SD3 is a very general system that doesnot specify any access control meaning for any predicatesand can be viewed as Cassandra without constraints, rolesand access control semantics. SD3 passes the proof treefrom its highly optimised policy evaluation engine througha simple and small proof checker to reduce the size of itstrusted computing base. This would be a technique thatcould also be applied to Cassandra.The problem of trust negotiation has been addressed in

[19], where various different negotiation strategies (which,when and in which order credentials are disclosed) are dis-cussed. Their Credential Access Policy (CAP) correspondsto Cassandra’s canReqCred rules specifying the prerequi-sites for credential disclosure. Cassandra’s uniform treat-ment of rules during evaluation gives us trust negotiationalmost “for free”, with a negotiation strategy similar totheir “Parsimonious Strategy”. It has been pointed outthat this strategy can leak information about possession ofcredentials without actually disclosing them. The “EagerStrategy” does not have this problem but is less efficient.[20] prevents the problem by adding another policy protec-tion layer. [22] argue that entities should be given the free-dom to choose their own negotiation policy. They identifya large family of strategies that are mutually compatible.

Conclusions and future work. We have developed atrust management system, Cassandra, with a role-basedpolicy specification language in which the expressivenesscan be tuned according to need by choosing an appropriateconstraint domain. Apart frommanagement of role permis-sions, activations and (cascading) deactivations, the systemalso uniformly provides flexible automatic credential re-trieval and automatic trust negotiation. With the constraintdomain we devised for the EHR case study, Cassandra’sexpressiveness surpasses that of existing systems while pre-serving a strong termination property. The policy languageis small, simple and devoid of any redundant constructssuch as delegation or hierarchies and yet it can expressa wide variety of policies. Cassandra, including the lan-guage, the access control engine and the goal-oriented dis-tributed policy evaluation algorithm, is fully and formallyspecified and thus amenable to formal reasoning.

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE

We plan to use Cassandra’s formal framework to provesecurity properties about specific policies. Along the samelines, we wish to formalise a low-level model of Cassandrathat specifies the underlying network protocols, the pub-lic key infrastructure and the design of certificates. We willalso investigate possibilities for making answers to requestsmore descriptive and user-friendly without leaking sensi-tive information.To gather more reliable test results, we need to build a

complete prototype that is truly distributed and uses digitalcertificates for sending credentials over the network. Wehope to improve efficiency by using a standard relationaldatabase for policy rule lookups. Such an implementationwill enable us to test real-world policies in a more realisticsetting, with millions of role activations and entities thatinteract via an unreliable network.

Acknowledgments We acknowledge support from aGates Cambridge Scholarship (Becker), a Royal SocietyUniversity Research Fellowship (Sewell), EPSRC grantGRN24872, and EC FET-GC project IST-2001-33234PEPITO. The authors thank Arne Heizmann for correctionsand comments. We also thank the reviewers for their valu-able comments.

References

[1] N. Baker and H. Sondergaard. Definiteness analysis forCLP(R). In Australian Computer Science Conference,pages 321–332, 1993.

[2] S. Barker and P. J. Stuckey. Flexible access controlpolicy specification with constraint logic programming.ACM Transactions on Information and System Security,6(4):501–546, 2003.

[3] M. Y. Becker and P. Sewell. Cassandra: Flexible trustmanagement, applied to electronic health records. In Pro-ceedings of the 17th IEEE Computer Security FoundationsWorkshop, June 2004. To appear.

[4] M. Blaze, J. Feigenbaum, and A. D. Keromytis. KeyNote:Trust management for public-key infrastructures (positionpaper). Lecture Notes in Computer Science, 1550:59–63,1999.

[5] M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized trustmanagement. In IEEE Symposium on Security and Privacy,pages 164–173, 1996.

[6] D. Clarke, J.-E. Elien, C. Ellison, M. Fredette, A. Morcos,and R. L. Rivest. Certificate chain discovery in SPKI/SDSI.Journal of Computer Security, 9(4):285–322, 2001.

[7] N. Damianou, N. Dulay, E. Lupu, and M. Sloman. ThePonder policy specification language. In Policy Workshop,2001.

[8] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, andR. Chandramouli. Proposed NIST standard for role-basedaccess control. 4, (3):224–274, 2001.

[9] C. A. Gunter and T. Jim. Policy-directed certificate re-trieval. Software - Practice and Experience, 30(15):1609–1640, 2000.

[10] J. Jaffar and M. J. Maher. Constraint logic programming:a survey. Journal of Logic Programming, 19/20:503–581,1994.

[11] T. Jim. SD3: A trust management system with certifiedevaluation. In Proceedings of the 2001 IEEE Symposiumon Security and Privacy, pages 106–115, 2001.

[12] N. Li and J. C. Mitchell. Datalog with constraints: A foun-dation for trust management languages. In Proceedings ofthe 5th International Symposium on Practical Aspects ofDeclarative Languages, pages 58–73, 2003 2003.

[13] N. Li, J. C. Mitchell, and W. H. Winsborough. Design of arole-based trust management framework. In Proceedings ofthe 2002 IEEE Symposium on Security and Privacy, pages114–130, 2002.

[14] N. Li, W. H. Winsborough, and J. C. Mitchell. Distributedcredential chain discovery in trust management: extendedabstract. In ACM Conference on Computer and Communi-cations Security, pages 156–165, 2001.

[15] P. Revesz. Introduction to constraint databases. SpringerVerlag, 2002.

[16] R. L. Rivest. Can we eliminate certificate revocations lists?In Financial Cryptography, pages 178–183, 1998.

[17] R. Sandhu. Rationale for the RBAC96 family of access con-trol models. In Proceedings of the 1st ACM Workshop onRole-Based Access Control, 1997.

[18] D. Toman. Memoing evaluation for constraint extensions ofdatalog. Constraints, 2(3/4):337–359, 1997.

[19] W. Winsborough, K. Seamons, and V. Jones. Automatedtrust negotiation. In DARPA Information Survivability Con-ference and Exposition, volume 1, pages 88–102, 2000.

[20] W. H. Winsborough and N. Li. Towards practical auto-mated trust negotiation. In Proceedings of the 3rd Inter-national Workshop on Policies for Distributed Systems andNetworks, pages 92–103, 2002.

[21] W. Yao, K. Moody, and J. Bacon. A model of OASISrole-based access control and its support of active secu-rity. ACM Transactions on Information and System Secu-rity, 5(4), 2002.

[22] T. Yu, M. Winslett, and K. E. Seamons. Supporting struc-tured credentials and sensitive policies through interopera-ble strategies for automated trust negotiation. ACM Trans-actions on Information and System Security, 6(1):1–42,2003.

Proceedings of the Fifth IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’04) 0-7695-2141-X/04 $ 20.00 © 2004 IEEE