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