Hi Erik,
I am concerned that the change you are proposing could be disruptive
to the overall structure of the PolicySet/Policy/Rule hierarchy,
where
Target is used to filter down to the Rules.
In order to meet the requirements that your example implies:
"For instance, someone may want to write a policy
which applies only to the internal users of a sub organization,
which requires matching the users organization attribute
to the organization of the resource.
This cannot currently be done at the policy or policy set levels.
"
namely that a Match in a Target be able to compare a Subject
attribute
with a Resource attribute, I think this could be easily done with a
simple
extension to the Match schema.
For example, the existing schema says:
<xs:element name="Match"
type="xacml:MatchType"/>
<xs:complexType name="MatchType">
<xs:sequence>
<xs:element ref="xacml:AttributeValue"/>
<xs:choice>
<xs:element ref="xacml:AttributeDesignator"/>
<xs:element ref="xacml:AttributeSelector"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="MatchId" type="xs:anyURI"
use="required"/>
</xs:complexType>
I think the following change would enable the capability you have
described:
<xs:element name="Match"
type="xacml:MatchType"/>
<xs:complexType name="MatchType">
<xs:sequence>
<xs:choice>
<xs:element ref="xacml:AttributeValue"/>
<xs:element ref="xacml:AttributeDesignator"/>
<xs:element ref="xacml:AttributeSelector"/>
</xs:choice>
<xs:choice>
<xs:element ref="xacml:AttributeDesignator"/>
<xs:element ref="xacml:AttributeSelector"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="MatchId" type="xs:anyURI"
use="required"/>
</xs:complexType>
This change should allow comparing, using Target/Match, attribute
values
from different entities, such as comparing a Resource attr value w a
Subject
attr value.
The 3.0 changes already allow ANDing a Subject attr val w a Resource
attr val,
which I think is very narrow functionality, however the proposed
change
above would sort of fill in the "missing piece" that the I think was
implied
by the intent of the 3.0 changes, but missing from the realization
of the
explicit mechanisms that made it into 3.0.
Thanks,
Rich
On 12/12/2011 2:57 AM, Erik Rissanen wrote:
All,
I have a proposal for a new combining algorithm. I don't want to
change the core spec at this point, so I suggest we do this
algorithm as a separate profile.
The background to this algorithm is that XACML does not allow
<Condition> elements at the policy or policy set levels.
This turns out to be a significant restriction in practice. I meet
it time after time in the real world.
Typically an XACML policy is written by subdividing the request
space into recursively smaller policies and rules. The targets at
the policy and policy set levels allow matching against constant
values, but not matching between two attributes or other more
complex expressions.
This is a problem since it is not unusual to require something
like that. For instance, someone may want to write a policy which
applies only to the internal users of a sub organization, which
requires matching the users organization attribute to the
organization of the resource. This cannot currently be done at the
policy or policy set levels.
For instance, assume that someone wants to write Policy A, which
should contain condition A. Ideally the user would like to define
this policy:
Policy A:
Target A
Condition A
Children of A...
This is not possible. It would be possible to push down the
condition A into all rules within Policy A, but that introduces
complexity, and also worsens performance since the condition will
not be applied at the higher level in the tree, where it could
eliminate a subsection of the policy tree. (Agreed, a smart XACML
implementation might find this redundancy and optimize for it, but
that complicates implementations.)
Another option is to work around this is to put the desired
condition _expression_ in a rule in a policy next to where one would
like pu the condition, and use a combining algorithm to deny
access if the condition in the rule does not apply.
PolicySet C, deny-overrides
Policy B
Rule B2 deny
Condition NOT A
Policy A
Target A
Children of A...
There are two problems with this. Firstly, the whole is more
complex, but that can be managed by a tool. The second problem,
which cannot be solved by a tool is that this is not fully
equivalent to what the user actually wants to do.
The problem is that if the condition A does not apply, the latter
approach returns a Deny instead of a NotApplicable, which the
former would do. The problem of this is that the deny will
propagate towards the root of the policy tree, putting
restrictions on what the other policies can be like since they
might be overridden by the Deny. This complicates policy
authoring.
So I suggest that we define a new combining algorithm. The id
should be:
urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:on-permit-apply-second
This combining algorithm accepts only two children, and will
return Indeterminate otherwise. If the first child is a Permit,
then the result of the combining algorithm is the result of the
second child. If the first policy is NotApplicable, then the whole
is NotApplicable. Otherwise the result is Indeterminate.
The normative pseudo code looks like this:
Decision onPermitApplySecondCombiningAlgorithm(Node[] children)
{
if (lengthOf(children) != 2) {
return Indeterminate{DP}
}
Decision decision0 = children[0].evaluate();
if (decision0 == NotApplicable) {
return NotApplicable;
}
Decision decision1 = children[1].evaluate();
if (decision0 == Permit) {
return decision1;
}
if (decision1 == Permit) {
return Indeterminate{P};
}
if (decision1 == Deny) {
return Indeterminate{D};
}
if (decision1 == Indeterminate) {
// Return the same flavor of Indeterminate as decision1.
// If decision0 == Indeterminate, use status code
// from decision0.
return decision1;
}
if (decision1 == NotApplicable) {
return NotApplicable;
}
}
Note that for simplicity I chose to return Indeterminate{DP} in
case of an incorrect number of children. We could instead have
evaluated the second child to figure out what the possible value
from the second policy would have been and adjust the
Indeterminate accordingly. But since we are checking for the
number of children, it's not sure that there is a second policy.
And this is an obvious error that tools or the PDP can check for
statically, so it's not worth introducing complexity for.
Also note that the last if statement is a bit interesting. In this
case there was an error in the application of the combining
algorithm when evaluating the first child, but the second child is
NotApplicable. I chose to return the NotApplicable in this case
because the whole could never be anything than NotApplicable in
any case. But this is a bit different from how for instance a
target is evaluated. If a target becomes NotApplicable, the whole
is Indeterminate, even if the children in theory could be all
NotApplicable. But I figured that since we have the information
available, we can as well use it. Alternatively we could skip the
whole processing of different flavors of Indeterminate, but since
the other algorithms do it, we may as well do it here.
Using this combining algorithm it will be possible to write policy
structures which are equivalent to a <Condition> in either a
policy or a policy set, without us having to change the core spec.
Authoring tools can hide this extra structure from users if
desired.
Best regards,
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
