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: Does the XACML 2.0 and 3.0 Subject have some inconsistencies in Coreand Multi Profile?

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
    • 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.

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:
    • "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:
    • "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:
    • "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.

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

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.


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