[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft proposal for new work item: properties for new combiningalgorithm
Hi, Anne
>1) As other have mentioned, "kitchen sink" elements are easily
> mis-used. Once introduced, they tend to develop a life of
> their own that impedes or prevents other rational extensions
> to the language.
I have no strong opinion to use arbitrary element in rules.
I think using <Attribute> element solves your problem.
>2) If we allow parameters that affect combining algorithms to be
> embedded inside the combined elements, we are effectively
> allowing the writer of the sub-policy or sub-rule to control
> evaluation of the enclosing policy. Until I see a good use
> case otherwise, I believe the writer of an enclosing policy
> must retain control of how the policy will be evaluated.
What I want to say is that a certain user-defined combining algorithm needs
extra information to evaluate the rule correctly. Please refer to my
message.
http://lists.oasis-open.org/archives/xacml/200304/msg00058.html
Regarding control of how the policy will be evaluated, I think that even if
any properties are accidentally inserted in the policy with the standard
algorithm, those properties must be completely "ignored" to avoid any side
effects on our existing semantics.
>3) How does the author of a sub-element know which combining
> algorithm will be applied to the sub-element? Parameters
> appropriate to combining algorithm A may be specified in Policy
> 1, but Policy 1 may be referenced from a PolicySet that uses
> combining algorithm B. In fact, the parameters supplied may
> have unintended effects when used with combining algorithm
> B.
In my opinion, rules are logically enclosed in the parent policy element
and the semantics of the properties specified in the rule is determined by
the rule combining algorithm defined by the vendor. Then both those rules
and the properties must be strictly attached to that algorithm. It never
happens that the rule is evaluated under different combining algorithm. If
this is the case, this is the mistake of rule administration.
> Do we force properties to
> have unique identifiers that associate them with a particular
> combining algorithm?
This is closer to what I have in my mind. Properties should be
algorithm-dependent and the meaning of the properties is defined only if
they are specified with that intended algorithm. So my idea is to use
algorithm-specific attribute name if it is specified as a property in the
rule. For example,
<Policy RuleCombiningAlgId="myAlgo">
<Rule>
<Property>
<Attribute AttributeId="myAlgo:propagation" DataType="String">
<AttributeValue>Upward</AttributeValue>
</Attribute>
</Property>
<Target>...
<Condition>...
</Rule>
</Policy>
Since <Property> element is NOT mandatory, the implementation does not have
to support <Property> element.
Anne Anderson
<Anne.Anderson@Su To: XACML TC <xacml@lists.oasis-open.org>
n.com> cc:
Subject: Re: [xacml] Draft proposal for new work item: properties for new combining
2003/04/23 23:14 algorithm
Please respond to
Anne.Anderson
Alternative proposal:
Define ordered versions of permit-overrides and deny-overrides
for XACML 1.1.
The only requirement we have so far is for priorities. I believe
priorities are best handled by adding evaluation order
requirements to combining algorithms (i.e. sub-policies or
sub-rules must be evaluated in the order specified).
Here are my additional concerns about the "properties for new
combining algorithm" proposal:
1) As other have mentioned, "kitchen sink" elements are easily
mis-used. Once introduced, they tend to develop a life of
their own that impedes or prevents other rational extensions
to the language.
2) If we allow parameters that affect combining algorithms to be
embedded inside the combined elements, we are effectively
allowing the writer of the sub-policy or sub-rule to control
evaluation of the enclosing policy. Until I see a good use
case otherwise, I believe the writer of an enclosing policy
must retain control of how the policy will be evaluated.
3) How does the author of a sub-element know which combining
algorithm will be applied to the sub-element? Parameters
appropriate to combining algorithm A may be specified in Policy
1, but Policy 1 may be referenced from a PolicySet that uses
combining algorithm B. In fact, the parameters supplied may
have unintended effects when used with combining algorithm
B.
The parameters could be tagged in some way according to the
combining algorithm to which they apply, but I think this
becomes unwieldy. Can you supply multiple sets of parameters
in a single Policy, each of which applies to a different
potential combining algorithm? Do we force properties to
have unique identifiers that associate them with a particular
combining algorithm?
Anne
On 22 April, Michiharu Kudoh writes: [xacml] Draft proposal for new work
item: properties for new combining algorithm
> From: "Michiharu Kudoh" <KUDO@jp.ibm.com>
> To: XACML TC <xacml@lists.oasis-open.org>
> Subject: [xacml] Draft proposal for new work item: properties for new
combining
> algorithm
> Date: Tue, 22 Apr 2003 19:09:55 +0900
>
> This is a draft proposal for a new work item regarding "properties for
new
> combining algorithms". XACML's extensibility allows local vendors to
write
> new combining algorithms.
> It is often the case that such algorithm uses algorithm-specific
parameters
> (e.g. rule priority number). But the current schema definition has no
space
> to specify such application specific parameters (or a too restricted
> schema)
>
> - Simple extension to support parameters for new combining algorithms
>
> There are several ways to support arbitrary parameters in the policy.
>
> 1) Add priority attribute in the Rule element
> 2) Add priority element below the Rule element
> 3) Allow to insert any element below the Rule element
> 4) Add a certain element (e.g. <Property> element) for a placeholder
that
> allows any element below it.
>
> The first two items are not appropriate since it is not applicable to
the
> cases where another parameter is needed (e.g. fuzzy parameter).
> The third might be good but it may conflict to the pre-defined elements.
> The fourth is more generic and better than the above. A sample example
is:
>
> <Policy>
> <Rule>
> <Property>
> <Priority>1</Priority>
> </Property>
> <Target>
> <Condition>
> </Rule>
> <Rule>
> <Property>
> <Priority>2</Priority>
> </Property>
> <Target>
> <Condition>
> </Rule>
> </Policy>
>
> I use <Property> element above which allows any element/attribute below
it.
> Next, there are several possibilities for the place where the <Property>
> element can be put.
>
> 1) Several elements can have <Property> but not all. (e.g. only
PolicySet,
> Policy, and Rule elements can have <Property>)
> 2) Any elements can have <Property>
>
> If we choose the first, the problem would be which elements are allowed
to
> have <Property>.
> If we choose the second, there is no problem about the extensibility.
>
> Once we come to agreement on the above issues, the next issue is how we
> modify the schema definitions. I don't discuss further in this proposal.
>
>
> - Another extension: support environment in target element
>
> The current policy model allows policy writers to specify policy on
targets
> of subject, resource, and action but not on environment. The conclusion
of
> the TC about not specifying the environment in the target was that 1)
usual
> access control policy consists of a access triple, that are subject,
> resource, and action, 2) environment variables such as current time do
not
> fit the limitations set on the target element.
>
> Setting aside the first item, some application will benefit if XACML
> supports environment in the target. For example, privacy protection
policy
> often consists of four arguments, that are subject, resource, action and
> purpose. In most cases, purposes used in a certain policy are on list
and
> they are described in the policy as equality checking (e.g. if subject
is
> Operator and purpose is order fulfillment, then permit the access). Its
> meaning is much closer to subject, resource, and action in the target
> rather than arithmetic computation using the current time and date time.
> One idea is to support purpose (or any attribute that policy writer
wants
> to specify) that can be used by a vender specific rule combining
algorithm.
> A sample privacy protection policy would be:
>
> <Policy RuleCombiningAlgId="DenyOverridesWithPurpose">
> <Rule>
> <Target>
> <Subjects>
> <Subject>... subject is operator </Subject>
> </Subjects>
> <Resources>
> <Resource>... resource is /order </Resource>
> </Resources>
> <Actions>
> <Action> ... action is read </Action>
> </Actions>
> <Environments>
> <Environment> ... purpose is fulfillment </Environment>
> </Environments>
> </Target>
> </Rule>
> </Policy>
>
> Therefore, my proposal is to allow <Environments> element and
> <EnvironmentMatch> element in the <Target> element.
>
> Michiharu Kudo
>
>
>
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]