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] Have the basic semantics of Target changed in XACML 3.0?- Is this an issue that needs addressing?


Hi Erick,

Thanks for the reply. I agree with your point that the same situation existed in 2.0, which I missed when I raised the potential issue, so I agree that there has not really been a semantic change, and therefore it does not seem reasonable to open an issue against 3.0 about it, either by introducing functionality of the type I mentioned, or even trying to "fix" the documentation.

However, after 3.0 completion, I do think it is an issue worth some investigation as to what the specs are really saying about the notion of "category" and whether any additional structure is desirable to firm up the concept.

In anticipation of potentially addressing this issue, post-3.0 completion, I will record here a couple suggestions that I think might initiate discussion at that time:
  • In XACML 3.0, section 3.3.1.1 Rule target (523-527) the current text says:
    • "3.3.1.1 Rule target
      The target defines the set of requests to which the rule is intended to apply in the form of a logical expression on attributes in the request. The <Condition> element may further refine the applicability established by the target. If the rule is intended to apply to all entities of a particular data-type, then the corresponding entity is omitted from the target."
    • Suggest changing the bolded text above by replacing "data-type" with "category":
      • "If the rule is intended to apply to all entities of a particular category, then the corresponding entity may be omitted from the target by omitting references to any attribute with that particular category in the target."
  • In XACML 3.0, section 5.6 Element <Target>, the current text says (1867-1870):
    • "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."
    • Suggest clarifying the above by saying that a "section" of the <Request> element is referring to an <Attributes> element of a specific Category. Also, by then saying that there MUST be a positive match between each <AnyOf> element AND any corresponding section of the <Request> element required within the <AnyOf> element.
      • I realize the above "clarifying" text is more confusing than the somewhat mis-stated existing text, but it indicates the nature of the cleanup that this suggestion is recommending.
  • also general cleanup of the use of the terms "issuer", "attributes", "category", "entity" in the spec. Specifically,
    • Glossary: the term "issuer" was added to refer to the <PolicyIssuer> introduced in 3.0. The glossary should probably be changed to identify this as the "policy issuer", plus change the defn of the term "issuer" to refer to the Issuer attribute of the <Attribute>, <AttributeDesignator>, etc. elements.
    • The term "attributes" is bolded in the earlier sections of the document, but used ambiguously in several cases, sometimes referring to an actual <Attributes> element and other times just simply being the plural of "attribute".
    • The terms "category" and "entity" appear to be used somewhat synonymously in a few cases including the first bullet above. Suggestion is to generally clean this up and more formally define the use of the terms, especially as they relate to the <Attributes> element.
I would suggest having this be an issue for post-3.0, possibly in the context of a 3.1 or an errata or maintenance update.

    Thanks,
    Rich




Erik Rissanen wrote:
4C15D854.8070803@axiomatics.com" type="cite"> Hi Rich,

Yes, and no...

Yes, it is true that in 3.0 one can mix different categories freely within the target. There is some discussion about this on the TC mailing list archive from the time when we made this change. The conclusion is that the current model is the right one because in fact 2.0 also had an equivalent structure because of the subject categories, which could be mixed freely within the subject section of the target. If we would not allow this mixing in 3.0, we would restrict the structure of the target compared to 2.0 and we would not be able to port 2.0 policies which use subject categories forward to 3.0. So, although it superficially appears that there was a big change, the answer is no, the structure of the target has not changed in a major way.

Regarding the exact wording in the spec, I don't think these are significant enough to do the whole 2 month cycle of revising the drafts, so I would like to leave them as they are.

Best regards,
Erik

On 2010-06-13 20:48, Rich.Levinson wrote:
4C152809.5050200@oracle.com" type="cite">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




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