[xacml] proposal for action-id, subject-id, and required Attributes

[Anne Anderson <Anne.Anderson@Sun.com>]

Issue:

  I am proposing that we not require a <Request> <Resource> to
  contain a "resource-id" Attribute, but instead that it MUST
  contain one or more <Attribute>s (not specified which) OR a
  <ResourceContent> element.  Previous e-mail describes this.

  But we are still left with which <Attribute>s, if any, are
  required for the <Subject> and the <Action>.

Proposal:

SUBJECT

  Set <Subject> <Attribute> minOccurs=2, and use the following
  wording:

  "Every <Subject> element MUST contain one and only one
  <Attribute> with AttributeId equal to
  "urn:oasis:names:tc:xacml:1.0:subject:subject-category".  This
  attribute indicates the role that the parent <Subject> plays in
  making the access request.

  Every <Subject> element MUST contain at least one other
  <Attribute> that describes the parent <Subject>.  Typically, a
  <Subject> element will contain an <Attribute> with AttributeId
  equal to "urn:oasis:names:tc:xacml:1.0:subject:subject-id"
  describing the identity of the parent subject.  A <Subject> may
  contain any number of other Attributes.

  More than one <Subject> element may contain an <Attribute> with
  the same value for "subject-category".  For example, the user
  executing the application making the access request may have
  authenticated using an e-mail name and an X500 Distinguished
  Name.  Attributes issued to the user under the e-mail name
  might be included in one <Subject> element along with a
  "subject-id" Attribute containing the e-mail name, while
  attributes issued to the user under the X500 name might be
  included in another <Subject> element along with a "subject-id"
  Attribute containing the X500 name.  Both <Subject> elements in
  this case, however, would have the value
  "urn:oasis:names:tc:xacml:1.0:subject:subject-category:access-subject"
  for the subject-category Attribute."

ACTION

  Set <Action> <Attribute> minOccurs=1, and use the following
  wording:

  "Every <Action> element MUST contain one and only one
  <Attribute> with AttributeId equal to
  "urn:oasis:names:tc:xacml:1.0:action:action-id".  This
  attribute specifies the action to be performed on the
  resource.

  If there is no separate value for the action (for example, the
  action is implied by the resource-id), then an action-id
  Attribute with a value of
  "urn:oasis:names:tc:xacml:1.0:action:implied-action" MUST be
  used.

  An <Action> element MAY contain an <Attribute> with AttributeId
  equal to
  "urn:oasis:names:tc:xacml:1.0:action:action-namespace".  This
  attribute specifies the namespace to which the action-id
  belongs.

  An <Action> element MAY contain any number of other
  <Attribute>s.

Discussion:
SUBJECT

  I think a <Subject> that does not have at least one Attribute
  is meaningless from a policy point of view: it could never
  affect the result of a valid XACML Policy.  Possible
  counter-example might be something like "Permit access if the
  CodeSource was NOT signed by XYZ.corp", but in that case, I
  think the same result is achieved by not having a <Subject>
  with a subject-category of "codesource" at all.

ACTION

  Hal has suggested that an Action should not have attributes,
  other than Id and optional NameSpace.

  An example of an Action attribute might be an assertion that
  the Action has been approved by the requester's manager.  Given
  this type of use case, I do not think we should prevent XACML
  policy writer's from using Action attributes.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692