OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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 with Haskell


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)

b



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]