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: Re: [xacml] DLP-NAC: Multiple Resource-IDs in a single request



Hi John,

On 13/12/2013 6:15 AM, Tolbert, John W wrote:

What is the best method to satisfy this use case (provided by NextLabs)?

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.

Policy authors need to be able to express that users cannot copy content from resource-id to another.  What is the expected behavior of the PDP when it receives an XACML request with two or more subject Resource-ID attributes?


Undefined.

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

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.

Regards,
Steven

 

 

1.1.1 Prevent sensitive data from being copied from one resource to another

Acme security policy prohibits copying proprietary information from one resource to another.  Alice attempts to copy sensitive data from one resource to a new one she just created.  The request fails.  Sample attributes and values are listed below.

 

Resource Attributes

Values

Resource-ID

http://confidential.acme.com/eyes-only.xml

Resource-ID

http://confidential.acme.com/in-the-clear.xml

Resource-location

webserver1.acme.com



Subject Attributes

Values

Subject-ID

Alice

Subject-ID-qualifier

acme.com



Action Attributes

Values

Action-ID

Copy

1.1.1.1 Description

This sample policy can be summarized as follows:

 

Target: This policy is only applicable if Resource-location = “webserver1.acme.com

AND Resource-ID contains “confidential\.acme\.com

 

Rule:  This rule is only applicable if Action-ID contains “Copy”

Then if

Subject-ID-qualifier = “acme.com” AND Resource-ID = Resource-ID

DENY

 




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