Hi Rich,
I don't want to change the core schema at this point. Also, there
are much more you can do in a condition than just comparing a
subject attribute against a resource attribute. I was using a very
simple example. Your proposal does not address any of tho other
requirements.
And this does not change the way "targets are used to filter down to
rules", since we already have combining algorithms and you can get
almost the same effect already, as I showed in my examples. The only
difference is that you don't need to handle the Denys which pop up
in that structure.
Anyway, I will implement this algorithm in the Axiomatics product
using our own identifier so our customers can benefit from it, but
it would be nice if it would be standardized instead since many
customers are concerned about interoperability.
Best regards,
Erik
On 2011-12-12 18:06, rich levinson wrote:
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: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org
|