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 withHaskell


Hi Bill,

bill parducci wrote:
> by this:
> 
> /*
> 
> What the model proposes is a delegation of rights model based on the 
> notions that:
> 
> * each access policy has an issuer associated with it
> 
> * a policy issuer can indicate whether the permitted rights can be
>   delegated to others or not
> 
> * a policy issuer can specify the maximum number of delegates in a
>   delegation chain that originates from its policy
> 
> For a PDP to evaluate an authorization decision based on a request and a 
> set of policies from potentially different issuers, the following 
> PDP-policies have to be defined:
> 
> * a root issuer (or maybe root issuers) have to be identified who are
>   trusted in an absolute sense
> 
> * a policy to combine decisions of different delegation depth
> 
> * a policy to combine decisions that are associated with different
>   issuers
> 
> */
> 
> trying to get my arms around 'absolute sense' here. are you suggesting 
> that there must be an explicit and/or federated issuer hierarchy 
> (policy) defined for each PDP (that spans the domain)? otherwise i am 
> not sure how this would work if two (or more) policies come from a 
> remote server where one of those polices is issued by an author who was 
> delegated rights by the issuer of the other policy (and there is conflict).

No, I'm already regretting that I added the "(or maybe root issuers)", and I 
just removed it from my local copy to avoid future confusion.

The idea was really that through such a *single* root issuer, a PDP is able to 
find those policies that are beyond any doubt, which are true, where it doesn't 
need any additional information, where the delegation chain should stop or be 
chopped off.

I never considered a federated issuer hierarchy - any hierarchy of the decision 
tree will be dynamically determined by the evaluated policy statements and the 
PDP's locally enforced combinator policies.


> i don't think that attaching delegation chain information to a policy 
> itself would solve the problem since there could be a case where the 
> issuer relationships may be unrelated to the rights associated with the 
> policy but the PDP may still wish to provide dominance. (the problem i 
> *think* that the "policy to combine decisions that are associated with 
> different issuers" is attempting to address, but i fear could result in 
> combinatorial explosion)
> 
> take the case of tom and harry each being delegated rights to control 
> access to abc by sue--making them peers WRT the policy itself--but harry 
> is a corporate manager and achieves delegative authority in the case of 
> 'ties'.
> 
> in other words, i can envision all sorts of weird combinations of 
> non-policy related issues affecting the pecking order. so, in addition 
> to the information proposed with each policy it seems that there should 
> be something that allows for conflict resolution.

One could think of many custom combinators that customers could create 
themselves, just like the current xacml would let you invent your own combinator 
(theoretically), but I'm not sure if I want to be associated with the definition 
of only the most simple combinators...and I sure wouldn't like to prove any 
correctness for these custom contraptions ;-)

> the only other options i can think of off the top of my head are:
> 
> 1. that interPDP policy exchanges contain some sort of preamble with an 
> unambiguous issuer hierarchy for that PDP (policy combination implied)
> 
> or
> 
> 2. a specific query is defined that allows a PDP to request the 
> relationship between a given number of issuers (aka a 'tiebreaker' query)
> 
> does this make sense? (without a white board i am more incoherent than 
> usual :o)

One combinator that could solve some interesting use case is a threshold one, 
where the combinator would only evaluate to permit if there are n-of-m issuers 
that grant that permission according to their associated policy statements.

A good example is the pilot scheduler case, where the pilot scheduler should be 
able to have the rights to "make" pilots fly, but who shouldn't have the rights 
to make him/herself fly.
This pilot scheduler example could be implemented with the current scheme if we 
would define so-called threshold-combinators, where combined policies would only 
evaluate to permit if there are n-of-m issuers that grant that permission. This 
would allow you to have a separate issuer different from the pilot scheduler who 
would give policy statements that would let all pilots fly always, and a 
combinator that would only yield permit if both these issuers would have policy 
statements that both would yield permit for a scheduled pilot.

This use case initially made me implement the delegation differently by having 
different kind of policy statements for access control and the administration of 
that access control. This, however, makes things quite a bit more complicated 
and more difficult to explain (as i discovered during the last f2f...), so I 
fell back on the easier approach, which would be good for a first step.

Thanks for the scrutiny!
Regards, Frank.


> To unsubscribe from this mailing list (and be removed from the roster of 
> the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php. 
> 
> 

-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory



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