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] Does the XACML 2.0 and 3.0 Subject have some inconsistenciesin Core and Multi Profile?


Hi Erik,

I see, at least at a high level, the points that were made:
http://lists.oasis-open.org/archives/xacml/200807/msg00002.html

A couple quick questions that may be related:
  • Does it say anywhere in XACML 3.0 that only one Attributes element with a specific Category should be allowed in a Request element?
    • I believe this is necessary, because otherwise one could include 2 Attributes elements w same Category, while at the same time providing different Content in each, which I do not think would be workable.
  • I am still concerned about the wording of the definition of Category in 3.0:
    • 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.
  • In particular, my concern is the phrase "or other categories". While I understand that there can be other "sub-categories", such as we have with variations on subject, I do not believe that there are any conceptual semantics for defining a category outside of the 4 main categories: subject, resource, action, environment. My recommendation is that we introduce the notion of sub-category, and possibly even require that any new "categories" that are introduced be prefixed by one of the 4 main categories, i.e. "subject-", "resource-", "action-", "environment-".
  • I also recommend that if you agree with my point about only one Attributes element with a given category and that there are four main categories of which new categories must effectively be sub-categories, that we may want to characterize a Request element as containing a set of Attributes elements, which each have a unique Category, which is a sub-category of one of the four main categories.
Hopefully, the above points are fairly clear. If there is disagreement as to whether my conjecture that we restrict categories to falling within one of the four main categories, then I would appreciate some explanation as to what kind of "category" outside of the four main categories that might be a reason that such a restriction would be undesirable.

    Thanks,      
    Rich


Erik Rissanen wrote:
4961BAC9.9020200@axiomatics.com" type="cite">
Hi Rich,

See responses inline.

Rich.Levinson wrote:
  
Hi Erik and TC,

Been looking at how the Subject evolved in 2.0 to 3.0 plus a possible
problem in 2.0 that may or may not carry over to 3.0.

First the possible problem:

    * XACML 2.0 section 2.4 describes the "intent" of "multiple
      subjects", which I think can be summed up as saying multiple
      identified Subject entities can be involved in a single access
      decision request. If there are multiple Subject elements in a
      Request then they are all potentially relevant to a single
      authorization decision and have a subject-category attribute
      that identifies what their "role" might be in the overall
      decision context.
    * Appendix B.2 enumerates 5 possible values of this
      subject-category attribute, and there may be additional ones
      defined by "users" (section 2.4).
    * Of the 5 values in section B.2, 2 of them,
      "intermediary-subject" and "codebase" have the statement "There
      may be more than one." in their defn, which I take to mean that
      a single Request element could have multiple Subject elements
      that contain one of these two categories.
    * The "problem" that I see is that section 6.2 lines 2921-2923 say
      that if there is more than one Subject element with the same
      SubjectCategory, they will be treated as if they were in the
      same Subject element
          o This appears to be a problem because, for example, if
            there are more than one "intermediary-subjects", then the
            attributes describing each will be mixed up together and
            one will not be able to tell which attribute in the
            Subject element pertains to which intermediary.

    

This has already been discussed on the list and there is an issue number
for it on the issues list. The issue was closed with no action since
"fixing" it introduces a huge amount of complexity since everything
retrieved from the request context then would become bags of bags of
attributes. You can find the discussion on the list. (Try to look for
emails around the date when the issue was closed.)

  
The above "problem" may or may not go away in 3.0. It appears that the
semantics of section 6.2 from 2.0 are "lost" in 3.0, because all the
"categories are now Attributes and the designators for Subject,
Resource, Action, Environment no longer exist, except as they are
buried in identifiers, and as 3.0 refers to them as "RECOMMENDED" in
XACML 3.0 section B.2.

Assuming that is ok (although I am becoming increasingly uneasy the
generalizing "Subject, Resource, Action, Environment" to "Attributes",
and allowing "Attributes" to go beyond those four conceptual entities,
may cause us to lose a lot of implicit semantics carried by the XACML
2.0 designations of these four entities), I noticed what might be
considered to be "creeping functionality" in the XACML 3.0 Multiple
Resource Profile. In particular:

    * The following sentence was removed from the 2.0 Multi-Profile
      from section 2.3.3 lines 232-234:
          o "Note that the semantics for multiple <Resource> elements
            are very different from the semantics for multiple
            <Subject> elements in a request context as described in
            the XACML core specification [XACML]."
    * In addition, the following sentence introducing section 2.3 in
      the 2.0 Profile:
          o "This Section describes use of multiple <Resource>
            elements in a request context to specify a request for
            access to multiple resources."
    * has been changed in the 3.0 Multi Profile to be:
          o "This Section describes use of multiple <Attributes>
            elements with the same category in a request context to
            specify a request for access to multiple resources *or
            requests for access by multiple subjects*."


The bottom line is that I don't think the access by multiple subjects
will work in the 3.0 profile, at least because there will now be no
way to determine which members of one subject-category are associated
with the members of the other subject-categories.
    

This was a decision made by the TC some time ago, to generalize the
multiple resource profile so it works the same way with other attribute
categories than the resource.

  
My recommendation is that at the very least, we pull back the multiple
subject notion from the multi-resource profile for now.
    

I think we can keep it. It's perhaps not as useful as the multiple
resource case, but we won't be able to do the "distinct subjects"
functionality anyway.

  
Also, I suggest that we put an errata in for 2.0 removing the lines
2921-2923 as they seem to contradict the intentions specified
elsewhere in the 2.0 document, which have also been carried forward to
3.0.

    Thanks,
    Rich

    

  


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