Attributes of Relations

The topic of "attributes of relations" came up during our work on the IPC profile that I would like to bring to the list for discussion.

For example, an intellectual property agreement (Copyright, Patent, Proprietary, etc.) is essentially a contract between parties (subjects) regarding the use of resources. The "agreement" is a relationship between subject and resource. The question of how to best model relationships like this with XACML attributes is what I would like bring up for discussion. So far two approaches to this problem have been proposed:

1.) Creating new attribute categories that would represent the relationships. Below is an excerpt from Hal regarding this approach.

2.) Determine the relationship at the PIP. This is one approach that IPC profile suggests regarding the use of the Agreement-Id, Valid-Agreement-Exists and Number-Of-Valid-Agreements attributes. Below is an excerpt from Erik on some of his thoughts on this topic.

- Richard

--------------------------------------------------------------------------------

On 2012-10-10 04:04, Hal Lockhart wrote (excerpt):

--------------------------------------------------------------------------------

...I have been aware for some time that the Categories of Subject, Resource, Action & Environment are insufficient as policies become more complex. The first use case I encountered of this kind was when trying to label certain operations as "Administrative". There is a need to associate the attribute not with the Resource or Action, but with the combination. For example, all operations on Usage Reports might be Administrative, whereas only creating an Account might be Administrative, other Account operations would not be.

Some Access Control Models consider Action to be a part of Resource, on the theory that to, for example, write a file and to write a database record are not really the same in important ways. I think the XACML treatment of Action as a first class Category has certain advantages, for example in the case where you want to write a policy about ALL reads or writes.

I have opposed using selectors to solve this problem for several reasons. First, it tends to hide what is intended in a complicated _expression_. Second, I think it is undesirable for references to attributes be dependent on the means used to obtain them. The foo attribute should be the foo attribute whether it came from LDAP, SAML or SQL. Also it makes the system fragile. If the attribute location changes, the policies have to change. I objected to Jan Hermann's proposal that we have Input Message and Output Message Categories for the same reason. Finally, I consider Selectors to be a mechanism to access attributes in the request context when a suitable designator has not (yet) been defined. Using a selector to access a repository seems like a kludge to me.

My preferred alternative in such cases is to define a new category type, say, Resource-Action. A possible objection is that we could end up with an explosion of Categories, but while this could be true, I think it comes from the real world nature of the problem and thus will be a feature of any solution. The selector will be different for every attribute and repository combination, possibly an even larger set.

Notwithstanding all that, I am not sure that is the problem in your case below. I don't think the patent, or copyright or license are attributes of the relationship, they are attributes of the Resource (document), The relationship is what you are trying to capture in the policy. For example, somebody has licensed Boeing to use this document. The policy says that since John Tolbert works for Boeing, he can use the document.

I think the problem in this case is that your attributes are not flat scalars, but contain multiple fields. I am not prepared to propose a data model, but it seems to me you problem is that the copyright attribute needs to be qualified by country and perhaps other fields. XACML requires new functions to deal with new attribute types as a whole, e.g. GeoXACML, but the existing functions can deal with one field at a time just fine.

Hal

--------------------------------------------------------------------------------

On 2012-10-09, 10:50 PM, Erik Rissanen wrote (excerpt):

--------------------------------------------------------------------------------

...There are different ways to deal with this issue. Defining a new category like you suggest Hal will not solve the problem because even if you have a new category, you cannot separate multiple instances of the same category, thus you cannot represent multiple relations this way.

My recommendation is to resolve the relations in a PIP. It puts some of the "logic" outside the XACML policy but it is the most pragmatic approach, since it does not need any extensions to XACML and leads to simple XACML policies.

Using complex data types, either in the form of xml <Content> and selectors, tuples represented as strings, or XACML data type extensions also work, but mean unwieldy expressions in policies or XACML extensions which need to be implemented in code in the PDP.

One idea I have been toying with in my mind for a long time has been to define a sort of generic tuple data type for XACML, but I have not been able to design a nice and clean set of operators on it, so I have not posted anything on the list. There is a suggestion like this on the XACML comments list, btw.

One could extend on this tuple idea, and when one thinks about the various operations which would be needed, one ends up re-inventing SQL, so I figured there is little practical value for XACML to do so. This can be done on the database side in a PIP. I guess there would be some value in terms of explicit

visibility, but I am not convinced, so I never pursued this thread of thought on the TC list.

Best regards,

Erik

xacml message