Re: [xacml] Does the XACML 2.0 and 3.0 Subject have some inconsistenciesin Core and Multi Profile?

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Erik,

I think I understand this a little better now:
There does appear to be semantic break with the Subject concept going 
from 2.0 to 3.0 in the multi-resource profile that is now expanded to 
include all categories, however, it may not be as problematic as it 
first appeared to me. The reason that there is a semantic break is the 
following:

    * In XACML 2.0 (and 3.0 for that matter), if there are multiple
      Subjects in a Request belonging to different
      Subject@SubjectCategories (or Attributes@Categories in 3.0), they
      are effectively treated as a Subject group, where each member of
      the group is checked accordingly in the Policies. I think this is
      fairly clearly stated in 2.0 section 6.1, lines 2884-2891
      augmented by the requirement in section 2.4 lines 433-438:
          o "...Therefore, XACML recognizes that there may be more than
            one subject relevant to a decision request. An attribute
            called “subject-category” is used to differentiate between
            subjects acting in different capacities."
    * Because the 3.0 multi-profile effectively iterates over each
      Attributes element in a given Category and creates an effective
      "Individual Resource Request" for each possible combination of
      Attributes elements where a combination may only contain on
      Attributes element from each Category.
    * Bottom line is that if multiple "grouped" subjects are put in a
      single request, then the members of the one grouped subject will
      get mixed up with members of other grouped subjects if their
      groups have members with common categories. By breaking up and
      mixing the subject groups, the profile "breaks" the semantics.

All that being said, I think the net effect in these "extreme" cases is 
that you end up with more answers than you want, but at least you do get 
the answers that you do want and would need to distinguish between them 
and the ones that you don't want (the ones where the subject groups were 
mixed).

I think that because most applications are going to only be dealing with 
single category subjects, that the benefit of making that kind of 
request easy for the multiple profile outweighs the possible 
inconvenience of getting extraneous information back for the presumably 
rare case where someone would batch a bunch of multi-category subjects 
in this profile.

Another point in this subject area has to do with the 2.0 "merging" (or 
"collapsing") of multiple subjects within a given SubjectCategory to a 
single Subject element for that one SubjectCategory. (see 2.0 spec: 
section 5.38 lines 2633-2634 and section 6.2 lines 2921-2923.) This 
effectively guaranteed in 2.0 that there was at most one Subject element 
within a given SubjectCategory. Therefore, despite all the mentions of 
"multiple subjects" in 2.0, there never was a concept of multiple 
subjects within a given SubjectCategory (although presumably one could 
have multi-valued subject-id attributes within a single SubjectCategory 
element).

Therefore, I think that 3.0 represents a change in this arena since I 
don't believe that there is any notion of "collapsing" multiple 
Attributes elements within a given Category in 3.0.

 From that perspective, 3.0 is really adding a new "dimension" to 
Subjects by allowing the multi-profile to process multiple Attributes 
elements within a given subject-category, which was not even 
conceptually possible in 2.0 because of the subject collapsing within a 
SubjectCategory.

Bottom line: I would recommend that it be noted in 3.0 core spec, 
possibly in the appendix for subject categories or maybe preferably in 
the 3.0 multi-profile that:

    * the ability to have multiple subject elements in a single subject
      category is new to 3.0.
    * care be recommended when attempting to use the multi-profile for
      multiple multi-category ("grouped") subjects for single decisions,
      because the profile will break up and mix the groups to have
      combinations in addition to the original grouped combination.

Final recommendation for future consideration:

    * if grouped subjects (or any other "grouping") is important to be
      cleanly supported in the multi-profile, that we probably need a
      means to give the members of the group an "id", for example an
      Attributes@GroupId attribute and that the multi-profile would be
      directed not to break up the "groups" with a common "GroupId".
      (this would mean that when someone submitted a
      multi-grouped-subject request that each "group" of subjects be
      given its own GroupId when added to list.

Thanks,
Rich


Erik Rissanen wrote:
> Hi Rich,
>
> The other categories may be user defined categories (not really
> recommended, but possible if users insist), the traditional XACML 2.0
> subject categories (which translate directly into attribute categories
> in 3.0) or the categories associated with delegation.
>
> For a regular XACML request only one element with a given attribute is
> allowed, anything else is an error. Multiple elements with identical
> categories are used in the multiple resource profile.
>
> Best regards,
> erik
>
> Rich.Levinson wrote:
>   
>> 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?
>>           o 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:
>>          o
>>
>>             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:
>>     
>>> 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
>>>>
>>>>     
>>>>         
>>>   
>>>       
>
>