[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]