[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Proposal on item 7 ConditionReference
On Tue, 9 Dec 2003, Daniel Engovatov wrote: > >We've argued this same concept before, and we have consistently said > that > >the <Policy> was the smallest unit of adminstration. > > > Smallest, yes. But not the largest unit of administration, I suppose? I agree. > We do have information shared between policies. Functions for example. > What is a fundamental difference between a function declared somewhere > else, and an expression declared somewhere else? Good point. However, with functions, you only run into problems when you venture from using just the standard functions. Then you are on your own, and that has always been the case. However, that is not the case with arbitrary expressions. We don't exactly have "standard" expressions for "standard" values. We do, we call them "constants". > Policy evaluation trusts data from the context, why not to trust a > dynamically computed data? The PEP is supposed to be *assured* that given a Policy, and a certain Request Context, it will get the same answer every time it asks for an evaluation of those two entities. This maintains integrity. Add the complication of referencing a value expressed, or calulated somewhere else leads to complications ensuring the integrity. You have to put forth a lot of machinery in the specificaiton. > In most cases a policy writer lives with the fact that a data type of a > particular attribute is fixed and defined outside of the policy. It is > not declared in the policy - only used. PIP function is to provide the > instance of the context, against which the policy is evaluated, and this > instance is shared between policies. Well, what does request context being "shared" really mean w.r.t. a policy? I don't think of the Request Context as entity that is being shared. It is merely an input specification to a function. Two policies may be evalated against the same request context, but that doesn't mean they are necessarily always sharing them. PEP1 --> PDP1 = PolicySet { PolicyRefA, PolicyB } PEP2 --> PDP2 = PolicyA Here, two PEPs, with 2 corresponding PDPs. True, any request context given to PDP1 is "used" by PolicyA and PolicyB each in their evaluations by the requirement of the encompassing PolicySet. However, it is NOT the case that *every* request context used by PolicyA is used by PolicyB as well, such as in when PEP2 asks PDP2 for an access decision. > It seems to me that there is nothing wrong with sharing not only static, > but also a dynamically computed context data - but that would require a > separate document to hold this policy data, with such a document being > the description of the context (attributes and functions declarations). Your PIP should calculate what it needs to and put it into the Request Context to be evaluated against the policy. > I agree that one <policy> should not reference anything in another > <policy> document, so currently we can not share indeed. Agreed. You are looking for something else in order to specify the calculation of the request context, but let us not complicate the argument here for simple variable definition and reference within a policy. Cheers, -Polar > > Daniel. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]