← Prev in month ← Prev in thread
Next in thread → Next in month →

Have the basic semantics of Target changed in XACML 3.0? - Is thisan issue that needs addressing?

From
Rich.Levinson <>
Date
2010-06-13T18:50:05+00:00
ID
Thread
Have the basic semantics of Target changed in XACML 3.0? - Is thisan issue that needs addressing?
To TC:

While perusing the core spec, I noticed what appears to be a possibly
subtle but significant change in the semantics of Target. In
particular, I think this subtlety shows up wrt the description of
Target in section 3.1.1.1, lines 526-528:

"If the rule is intended to apply to all entities of a
particular data-type, then the corresponding entity is omitted from the
target. An XACML PDP verifies that the matches defined by the target
are satisfied by the attributes in the request context."

Also relevant to this discussion is the term "entity" used above, that
also shows up in section 5.9 lines1908-1909:

"The <Match> element SHALL identify a set of
entities by matching attribute values in an <Attributes>
element of the request context with the embedded attribute value."

The "change in semantics" I am talking about can be fairly clearly seen
be comparing the above text to its counterparts in XACML 2.0.

In 2.0 section 3.1.1.1, lines 642-645:

"If the rule is intended to apply to all entities of a
particular data-type, then the corresponding entity is omitted from the
target. An XACML PDP verifies that the matches defined by the target
are satisfied by the subjects, resource, action and environment
attributes in the request context."

and for example, in 2.0 section 5.8 on SubjectMatch, lines 1964-1966:

"The <SubjectMatch> element SHALL identify a set
of subject-related entities by matching attribute values in a
<xacml-context:Subject> element of the request context with the
embedded attribute value."

The "problem" that I think may have been introduced is that when
policy-side <SubjectMatch>, <ResourceMatch>,
<ActionMatch>, <EnvironmentMatch> were reduced to a generic
<Match> in 3.0, that the implicit "category" or "entity-type",
conveyed by "Subject", "Resource", "Action", "Environment" was not
included in the policy-side definitions. However, it was retained on
the Request side with the Category element defined on lines 2794-2798:

"Category [Required] 

This attribute indicates which attribute category the contained
attributes belong to. The Category attribute is used to
differentiate between attributes of subject, resource, action,
environment or other categories."

What I believe is needed is some notion of "Category" on the Policy
side. As it stands now, it appears to me that Target can contain a
random selection of AttributeSelectors and AttributeDesignators, which
are unrelated by Category in the <AllOf> and <AnyOf>
elements of Target, which previously were represented by
<Subject> and <Subjects> elements in 2.0 (as well as
corresponding for Resource, Action, and Environment).

As it stands statements like the one at the top of this email where it
is stated:

"If the rule is intended to apply to all entities of a
particular
data-type, then the corresponding entity is omitted from the target."

do not appear to have any meaning. Note that it appears that
"data-type" was not used properly in these statements, and that it
probably should be replaced by "entity-type" both in 2.0 and 3.0. I am
not aware of any interpretation of the above statement where
"data-type" has any semantic meaning in the XACML sense. Clearly, the
things that are omitted are Subject, Resource, Action or Environment,
or in 3.0 any specific "Category". However all these "entities" or
"categories" can contain a set of Attributes with differing
"data-types" to which no significance in this context is relevant.

Another example of a possibly "meaningless" statement is in section
5.6, lines 1867-1869:

"The <Target> element SHALL contain a conjunctive
sequence of <AnyOf> elements. For the parent of the
<Target> element to be applicable to the decision request, there
MUST be at least one positive match between each <AnyOf> element
of the <Target> element and the corresponding section of the
<Request> element."

I do not see how there is a determined a "corresponding section" to an
<AnyOf> element. Because there is no Category on the AnyOf
element there is no restriction on the Category of any of the
descendant Attribute Designators or Selectors, and if there are more
than one Category associated with different Match elements within an
AllOf, then there is no "upward" way to set an unambiguous Category.

Possibly the <AnyOf> and possibly the <AllOf> and
<Match> elements could use a Category xml attribute to restore
the original intent of the Target semantics? i.e. the point would be to
restore the connection between the groupings of Match statements within
AnyOf, AllOf, and the specific Category in the Request. Also, I allow
for the possibility that this is an unnecessary restriction, which I
recognize that technically it is unnecessarily, but semantically, has
it been so generalized as to totally lose the intended semantics?

Also, I recognize that Category is a required attribute of the
AttributeSelectors and the AttributeDesignators, however, there appears
no restriction by <Target>, <AnyOf>,<AllOf>, or
<Match> which would control their grouping within the Target.

Also, I recognize that the old semantics can be retained by
"convention" for Policy designers, but this is a "convention" that was
not required by 2.0. 

Maybe I have missed something, in which case we can put this in the
"Never mind" folder.

    Thanks,

    Rich
← Prev in month ← Prev in thread
Next in thread → Next in month →