OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] New algorithm proposal


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]