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

[Erik Rissanen <erik@axiomatics.com>]

Hi Rich,

I think your analysis is correct.

Regarding grouping different subject categories so you don't get 
multiple answers, I think this could be covered by the boxcarring which 
Hal proposed earlier. We decided to put boxcarring into the multiple 
resource profile, but I don't recall anymore who has an action to make a 
schema proposal. It might be me.

Best regards,
Erik

Rich.Levinson wrote:
> 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
>>>>>
>>>>>             
>>>>         
>>
>>   
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php