|Subject:||Re: [xacml] Modeling Delegation of Rights in a simplified XACML with Haskell|
|From:||Bill Parducci (bill...@overxeer.com)|
|Date:||Nov 21, 2003 6:43:04 am|
Frank Siebenlist wrote:
In the presented model, anyone can can issue a "deny-policy", which becomes only valid if that person was issued a permit him/herself.
In other words, having the right to access some resource gives me the right to delegate those rights to someone or to explicitly deny those rights of someone. (I can think of schemes that would treat deny differently from permit, but I hope we can stay away from the associated additional complication...)
ok, so if i can only READ a resource i can issue denies only to READ it?
then if i read your earlier proposal correctly, does that mean that if i attempt to issue a deny on WRITE and READ to that resource, the policy is discarded from the overall decision because i am not allowed to 'issue a policy re:WRITE' (even though as part of the same policy i have a rule re:READ')?
personally, i don't think we can stay away from schemes that don't address an issuers explicit capabilities (e.g. 'frank can issue policies on xyz of scope READ/WRITE/DELETE/CREATE').
When you talk about a delegated topology of thousands, what kind of a scary use case do you have in mind?
oh i dunno, let's pick some sort of multi-tiered sales approach (phone cards) where you could have hundreds of individuals who have the ability to grant access to a virtual phone card system from their website. it would seem that any time were you have a large number of entity pools (i don't want to get into federation at this point ;o) where you can't simply stick someone in a group to provide access, but have to treat them independently this situation could arise.
As stated above: i can only explicitly deny tim the right to read abc, if and only if I myself have been granted the explicit permission to read abc. The latter yields either by a direct decision of the root issuer, or by a decision chain of only permit decisions that end at the root issuer (and doesn't violate any maximum delegation depth policies along the way)
Furthermore, if i have been explicitly denied the right to read abc, then no one should care whether i state that tim should be denied or permitted to read abc: my policy should evaluate to a NotApplicable.
again, what i worry about are situations where policies may be subject to interpretation as to applicability. for example, suppose i choose to implement a system that ignores (N/A) any policy that makes a statement that exceeds the issuers ability even if there are valid declarations. on the other hand, you may decide to create a very clever system that simply applies only those aspects of each policy that are within the issuers current sphere of influence*. how do i ensure deterministic results without some sort of root/metapolicy? i don't see how a policy combinator would handle that since it involves the evaluation strategy of a policy not how to combine the results to another policy.
*it is important to note for those following along at home that this model does not allow for the filtration of policies at creation time with respect to the issuer's ability to generate polices because the evaluation MUST be performed dynamically during policy evaluation. i think this is important because with the ability to deny access we run the risk of introducing Unintended Consequences to overall policy decsions based on polices changes that affect the rights of issuers.
example (deny overrides):
root policy says everyone can read, write, delete to file X
tom's policy says harry cannot read, write nor delete file X.
betty's policy takes away toms ability to delete file X.
PDP doesn't apply tom's deny policy because he cannot make policy re:delete on file X.
harry reads, then deletes file X.
ok, my head hurts now. :o)