CSE394: Security Policy Frameworks
	       Scott Stoller, 20oct2005
	      Extended API for Cassandra

the new API supports addition and deletion of all rules and facts, 
not just role activation facts.

it thereby supports administrative control over policy changes.  
it also allows facts to be added and deleted to auxiliary relations
directly, instead of encoding them as role activations and
deactivations.

special relations
-----------------
permits(e,a): entity e may perform action a

canReqCred(e, cred): e is authorized to obtain credentials
that match cred, where cred has the form iss.p(args) <- constraint.

delete(r(args)): the fact r(args) is being deleted.  
(this is a generalization of isDeactivated.)

special actions
---------------
addRule(rule)
deleteRule(rule)

note: addRule and deleteRule can be used to add and delete facts,
which are simply rules with no hypotheses.

API
---
e:doAction(a).
e:requestCredential(cred)

note: the action a may be one of the special actions above, or an
application-specific action.

pseudo-code for API operations
------------------------------
e:doAction(a):
if not (policy |- permits(e,a)) then skip (or return "denied")
else match a with
  addRule(r): 
    if r is in policy then skip (or return "error")
    else insert r in policy
  deleteRule(r): 
    if r is not in policy then skip (or return "error")
    else delete r from policy
	 if r is a fact p1(args1) then  // process cascading deletions
**	   add delete(p1(args1)) to policy
**	   D = { delete(p(args)) | policy |- delete(p(args)) }
	   for each delete(p(args)) in D
	     delete p(args) from policy if present
  otherwise: perform action a on the resource  (or return "permitted")

note: an alternative semantics for cascading deletions is obtained by
replacing the two lines marked with "**" with
 D = the least solution to the fixed-point equation
   X = { delete_p(args) | 
         policy union {delete(p1(args1))} union X |- delete_p(args) }
which semantics is more natural?

note: "policy |- fact" means that the fact is derivable from the policy

e: requestCredential(iss.p(args) <- cReq): same pseudo-code as with
the old API.


Implementation of Cassandra API
-------------------------------

to demonstrate that this new API is as expressive as the old API, 
we show to implement the old API using the new API.

e:doAction(a): as above

e:requestCredential(cred): as above

e:activate(r): e:doAction(addRule(hasActivated(e,r) <- true))

e:deActivate(r): e:doAction(deleteRule(hasActivated(e,r) <- true))

Existing Cassandra policies need to be re-written as follows.

replace canActivate(e,r) <- hyps
with    permits(e, addRule(hasActivated(e,r) <- true)) <- hyps

replace isDeactivated(e,r) with delete(hasActivated(e,r)) 
in the hypotheses and conclusions of all rules.