RE: [xacml-comment] XACML 1.0 Committee Specification Comments

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

On 11 December, Chopra, Dipak writes: RE: [xacml-comment] XACML 1.0 Committee Specification Comments

> When I read the line #354, 355, I got the impression that
> this is about creating policy sets, but this is about combining
> rules and policies to evaluate authZ decision. I think changing
> the term "action" to "access request" makes it clear. At the same
> time, the objective of combining rules and
> policies is to evaluate the consolidated authorization decision
> and not to create a policy set(?). I would say statement like "To
> provide a method for combining individual rules and policies to
> evaluate authZ decision that applies to a given access request"
>is more clear. Lines #400-403 indicate the same.

Your alternative wording would probably be a little more clear.
I hope the current wording is acceptable, however.

 > > 9. There are two different types of resources. Functionality
 >  > resource and data-instance resource. For example, ManagePO
 >  > resource can be used to create/delete/modify an instance of
 >  > PO. So ManagePO is a type of functionality type resource and
 >  > instance of PO is a data-instance type resource. If we need to
 >  > mandate that this action of this data-instance type resource
 >  > can only be permitted by this functionality-type resource, how
 >  > do we enforce that?
 > 
 > If I am understanding you correctly, this could be enforced by
 > having the ManagePO "resource" be expressed in the Action element
 > of the Request, and the "PO" be expressed in the Resource element
 > of the Request.  In other scenarios, it might make sense for the
 > ManagePO "resource" to be an attribute of the PO resource.
 > 
 > <dc>Your solutions make sense. Although I got the idea. I just
 > want to be sure, so here is my understanding of your
 > solutions. 
 > a. If we have the ManagePO "resource" expressed in Action
 > element, and then the corresponding "Rule" must have
 > "Condition", which checks the existence of two
 > "ActionAttributeDesignator" elements, for example "createPO
 > and ManagePO", "deletePO and ManagePO", "modifyPO and
 > ManagePO". 

We talked over your use case at the XACML Comments Subcommittee
meeting yesterday, and decided that "ManagePO" is probably more
correctly expressed as a Subject.

From here on, I am expanding on what the subcommittee discussed.
You could use a Subject with SubjectCategory
"urn:...:intermediate-subject" to hold attributes of "ManagePO",
and a Subject with SubjectCategory "urn:...:access-subject" to
hold attributes of the user executing the "ManagePO" application.

One way of expressing Rules for using ManagePO follows:

Each Rule Target could list
- "ManagePO" as a required Subject with SubjectCategory
  "urn:...:intermediate-subject",
- "PO" as the required Resource,
- and one of the particular "ManagePO" actions as the required
  Action.

The Condition could then state which Subjects with
SubjectCategory "urn:...:access-subject" are allowed to use
ManagePO to perform that Action on PO: for example, all Subjects
with having an attribute that makes them eligible to run
"ManagePO" for that action, or all Subjects whose subject-id
attributes are in a particular RFC822 domain.

 > To check the existence of two attributes, we can use the
 > logical function "present". The "Condition" can enforce that
 > "present" function result on both attributes is same.</dc>

The current specification does not have a logical function
"present".  You may now set an xml attribute "MustBePresent" to
"true" on an AttributeDesignator.  If the designated attribute is
not present, the AttributeDesignator will return "Indeterminate".

If you do not use "MustBePresent", then a missing attribute will
return an empty bag of values from the AttributeDesignator.  You
can get the size of this bag for using the "bag-size" function,
and check it for size >= 1 using the
"integer-greater-than-or-equal" function.  Or you could use the
"*-one-and-only" function around each AttributeDesignator.

You could also filter for one of the required Attributes in the
Rule Target, and then check for the other one (using one of the
methods just described) in the Condition.

There are other ways to do it too.

Anne Anderson
-- 
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