[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Modeling Delegation of Rights in a simplified XACML withHaskell
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]