Re: [xacml] Modeling Delegation of Rights in a simplified XACML withHaskell

[Polar Humenn <polar@syr.edu>]

Frank,

Could you give us the use case for your paper? The paper doesn't quite
describe it, and I'm having trouble figuring out what you really want to
do other than abstractly.

To me, it looks like you just want to set up a chain of delegations being
that anybody that is allowed access has the right to give it away.  I am
not sure why the "issuer" comes in on this point, and it seems to cause
problems, such as you note by having decisions "issued" by different
principals and the complicated combining algorithms. However, you use the
issuer and subjects as an explicit connector between policies.

Furthermore, it looks like you had to refine the policy such that a
subject is no longer a general predicate that is matched against arbitrary
subject attributes.  You make it to match an explicit principal, so
presumably, that you can correlate the subject in the policy exactly with
another policy issuer, or visa versa.

Let me take a stab at something. For the moment, let me make use of the
Abadi Principal Calculus. I think what you really want to say is that
there are principals that can "speak for" another principal, and these
successive "speaks for" relations can form your delegation chain, but we
can take the "chain" complications out of it.

We will take advantage of a rule:

A says s       B speaksfor A on s
-----------------------------
     A /\ B says s

where "/\" effectively means a conjunctive principal, i.e. they both say
s by themselves

     A /\ B says s
-------------------------
A says s     B says s

Lets say the question is can Alice access resource Boat with action Drive.

Alice says "Drive:Boat"

Let's say our policy does not know anything about Alice, such that the PDP
would return NotApplicable. However, it's John's boat, and if the
question were asked of John,

John says "Drive:Boat"

the PDP would return Permit.

John wants Alice to drive his boat, so he might be able to convince the
PDP that Alice "speaks for" John on that particular resource and action.

Alice speaksfor John on "Drive:Boat"

Then when the question is asked on

Alice says "Drive:Boat"

the PDP calculates in any speaksfor relations it has, and therefore you
have the combined question"

Alice /\ John says "Drive:Boat"

Since John is allowed to drive the boat, and

John says "Drive:Boat"

is deduced from the conjunctive statement, then John's access rule will
fire and a Permit will be the result.

This way, you don't have the problematic "Permit/Deny" delegation
chaining, especially if "John says "Drive:Boat" yields a Deny, then Alice
will be denied as well.

We can write rules with targets and conditions as we do now, which will
keep the predicates on subjects, resources, and actions, in general form.
And all we really need to do is deal with conjunctive principals, which is
something we wanted to do anyway.

The rules for the "speaksfor" can have almost the same format for the
access rules. Instead of "emitting" a Permit or Deny effect, it emits a
Subject (i.e. set of SubjectAttributes).

These "speaksfor" rules can be placed in a special section, or I think,
less intrusive to what we have now, as arguments to a combining algorithm,
which we might do as well.

This way the combining algorithm may calculate the "speaksfor" relations
before hand (there is still a recursive problem, but there is a least fix
point) which will "enhance" the request with the added subjects. Then the
constituent policies may be evaluated on those subject attributes.

How does that sound?

-Polar