Re: [xacml] [Issue] How many resourceIds in request context?

[Seth Proctor <Seth.Proctor@Sun.COM>]

On Mon, 2004-01-05 at 11:33, Anne Anderson wrote:
> Some people, including Hal and, I think, Seth, believe that there
> absolutely must be one and only one resource-id attribute.  The
> reasoning is that any Request must at least specify the
> resource-id in order to know what is being accessed.

I don't know why you think I have such a strong opinion on this. I don't
think I've ever weighed in on this matter. I do believe that the spec
currently requires a valid Request to contain exactly one resource-id
attribute, so that requirement is in my open source project.

> I disagree with this view.  I believe a resource could be
> described via attributes other than its resource-id.  For
> example, a Request could ask for access to a resource that has a
> security label of "Top Secret".  The policy may not care what the
> resource-id is, but is willing to grant or deny access based on
> whether the Subject has a corresponding security clearance
> attribute.

As it currently stands (see below) you can include any of these kinds of
attributes, as long as you also name the resource in question. In your
system you may not care about a resource identifier, so your PEP might
always just include some placeholder. There's nothing in the XACML
specification that keeps you from doing exactly what you've described
here.

> If we ever support partial evaluation, then cases arise in which
> there may be no resource attributes in the Request at all,
> because any resource attributes have already been factored out of
> the policy to be evaluated.  This applies also to subject and
> action attributes.

I think if we ever decide to support partial evaluation, we will have to
revisit several issues. For the time being, a separate question is
whether it's worthwhile to allow a Request with no identified Resource.
I can't see this being used very often, but I can think of some use
cases (for instance, an OS asking if a given user is allowed to invoke a
given kernel function, regardless of the resource). Again, these can be
supported now (see above), but it would be cleaner to make the resoruce
optional. I'm probably easy either way.

Now, as to Tim's orginal question (which you didn't actually address, I
don't think)...

> On 5 January, Tim Moses writes: [xacml] [Issue] How many resourceIds in request context?
>  > From: Tim Moses <tim.moses@entrust.com>
>  > To: 'XACML' <xacml@lists.oasis-open.org>
>  > Subject: [xacml] [Issue] How many resourceIds in request context?
>  > Date: Mon, 05 Jan 2004 11:12:20 -0500
>  > 
>  > Colleagues - In section 6.3 of v1.1 we define the syntax for
>  > <xacml-context:Resource> thusly:  
>  > 
>  > 	<xs:element name="Resource" type="xacml-context:ResourceType"/>
>  > 	<xs:complexType name="ResourceType">
>  > 		<xs:sequence>
>  > 			<xs:element ref="xacml-context:ResourceContent"
>  > minOccurs="0"/>
>  > 			<xs:element ref="xacml-context:Attribute"
>  > minOccurs="0" maxOccurs="unbounded"/>
>  > 		</xs:sequence>
>  > 	</xs:complexType>
>  > 
>  > Consider the 5th line (... ref="xacml-context:Attribute" ...).
>  > 
>  > Below, we say:
>  > 
>  > "The <Resource> element MUST contain one and only one <Attribute> with an
>  > AttributeId of "urn:oasis:names:tc:xacml:1.0:resource:resource-id"."
>  > 
>  > The "minOccurs="0"" in line 5 and the "one and only one" below it appear to
>  > conflict.

As the specification stands now, the minOccurs line isn't needed. There
will always be at least the resource-id attribute. I don't see any
problems with removing that constraint.

>  > I expect we mean "no more than one".  Can I go ahead and change this?  All
>  > the best.  Tim.

Sorry, I don't follow here. Where do we mean "no more than one"? The
Resource section may certainly contain more than one Attribute, though
it must always contain at least one. I think that the text is right, and
the schema should change (if we stay with the current requirement). If
we decide to make the resource-id attribute optional, then obviously
both text and schema should change.


seth