Subject: Re: [xacml] DLP-NAC: Multiple Resource-IDs in a single request
On 13/12/2013 6:15 AM, Tolbert, John W wrote:
While it is not possible to absolutely enforce a prohibition on copying of information
that at any point is visible to the user, I am aware of document viewing applications
that lock down copy and paste functionality to at least make it difficult for users to
copy documents. Though not perfect, such restrictions may be adequate from a
contractual point-of-view to demonstrate that the application took all reasonable steps
to prevent copying, or to claim that a user must have knowingly breached an agreement
to not copy the information. I'll assume that application-provided copy-and-paste is the
action that is to be allowed or disallowed.
In the ViewDS PDP, if there are multiple resource-id values we check that they all refer
to the same resource. If not, then the PDP will not attempt to retrieve any additional
attributes about the resource from a PIP. It will just use the attributes appearing in the
request. We do a similar thing when there are multiple subject-id values. Thus we expect
multiple identifiers to be alternatives for the same entity. Other PDPs may treat them
That aside, you have the problem that a policy cannot distinguish between the identifier
for the source and the identifier for the destination.
If the decision doesn't depend on attributes of one of the resources, then a simple
solution is to put the identifier of either the source or destination resource in a separate
attribute. I would make it a new attribute in the action category since it looks to me like
a property of the action (the resource being copied from/the resource being copied to).
In general, I think the authorization decision will depend on attributes of both the source
resource and the destination resource. For example, the decision may depend on the
security classification of each document. To prevent ambiguity, the attributes of the source
and destination need to be in different categories. There are a number of ways to achieve that.
You could define a new category for destination-resource or source-resource, depending
on whether you want the existing resource category to be used for the source resource
or destination resource, respectively. The attributes of the new category could be any
attributes that normally appear in the resource category.
If you use the Related and Nested Entities Profile, then you could make either the source
or destination resource an entity nested in the action category, or a related entity
referenced by a URI attribute in the action category. Or if you don't want to play favourites,
nest or refer to both the source resource and the destination resource using separate
attributes in the action category and not use the existing resource category at all for
the copy-and-paste action.