RE: [xacml] Attributes of Relations

[Mohammad Jafari <mjafari@edmondsci.com>]

Hi Erik,

The example you mentioned is in fact implementable in quite a few ways. For example, we can define an attribute "subscription" over "subject", "action/device-context", "resource/store" and "environment/location" (see the attached file) and assume that the PIP inserts the value of this attribute by checking the backend. Or we can define the attribute only over "subject" and "action/device-context" and define location as one of its attributes and assume that the PIP give the list of all such subscriptions. The more we present the attributes explicitly in the request context, the less we rely on the logic hidden behind the PIP, but also the more we need advanced functions in the PDP (e.g. a "where" function that returns a new att. bag from a given att. bag based on some criteria.) 

I think the important point is that we must fix/extend the data model so that we can capture the attributes in a structurally sound way. Once that is done, making comparisons will in the worst case be a matter of defining some custom functions (we can also allow defining composite functions over existing functions, the way we allow defining variables in the policy).

I agree with your (a few others') points that somehow we are re-inventing SQL here, but I think if we look at it from the perspective of relational algebra, SQL is nothing but a data model and a set of functions (relational operators). So simulating SQL does not need much of a change other than fixing the attribute data model to allow more complex data structures.

Regards, 
Mohammad

-----Original Message-----
From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Erik Rissanen
Sent: Wednesday, December 19, 2012 6:35 AM
To: Mohammad Jafari
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] Attributes of Relations

Hi Mohammad,

I am not sure that this solves the kind of requirement which we are facing in the IPC profile.

Can you express the following?:

The subject has purchased two subscriptions for a music service:

Subscription 1:
- Subject: alice
- access device type: iPhone
- Permitted access location: US

Subscription 2:
- Subject: alice
- access device type: XBox
- Permitted access location: EU

Now, the subject is trying to access tune using her iPhone while traveling in the EU:

Subject:
   subject-id = alice
   accesss-device = iPhone
   location = EU

Can you write a policy which correctly detects that there is no matching subscription?

The problem with plain XACML is that if you flatten the attributes of the available subscriptions into the request, then they get mixed up, like this (I use the environment category, but that is pretty arbitrary):

Subject:
   subject-id = alice
   accesss-device = iPhone
   location = EU
Environment:
   subscription-device = iPhone
   subscription-device = XBox
   subscription-location = US
   subscription-location = EU

Now you cannot tell which location is for which device.

Your hierarchy of attributes probably can capture the attributes so they don't get mixed up, but I did not see any operators in your proposal which can _simultaneously_ check for both conditions in a single relation, as is required in this example. (Please correct me if I am
mistaken.)

And keep in mind that we may not want a simple equality test, rather other operators as well in other cases. Also, there might be relations between relations which we want to check.

This whole thing appears quickly to balloon into reinventing the wheel of SQL or something similar.

Best regards,
Erik

On 2012-12-17 19:16, Mohammad Jafari wrote:
> Hi Richard, Steven and Erik,
>
> I think the so-called relationship-based access control [1] has a lot of other applications especially in social networks and personal healthcare access control use-cases. So, I think modeling relations and their attributes is worth some clean and direct support in XACML, in next updates.
>
> I have written some thoughts in the attached draft. In summary, my suggestion is to:
> 1) Simplify the XACML language to a pure attribute-based model. This is in-line with the XACML 3.0 approach of removing Subject, Resource,... I think subject, resource, actions, can be considered to be attributes of the Request.
> 2) Allow a recursive structure for defining *attribute of other attributes* to support modeling complex data structures.
>
> The attached draft contains some detailed examples with corresponding request contexts and policy clauses. Please let me know what you think.
>
> Mohammad
> Security Architect,
> Edmond Scientific Company
>
> [1] Fong, Philip W.L., Relationship-based access control: protection model and policy language, CODASPY '11: Proceedings of the first ACM conference on Data and application security and privacy, pp. 191-202, San Antonio, TX, USA.
>
>
>
>
> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] 
> On Behalf Of Erik Rissanen
> Sent: Monday, December 17, 2012 8:19 AM
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Attributes of Relations
>
> Hi Steven,
>
> My point in my email was that you cannot just flatten attributes like that, as you describe yourself, but also that I don't think it is worth doing in XACML.
>
> One option is to extend XACML. There are multiple ways to do that. One is to define a tuple/relation datatype and operators on it, which I think is a relatively nice and clean solution. Another one is what you propose is to iterate over categories, which I don't quite like as much since it appears more kludgy than well established relational algebra on tuples. We could debate this...
>
> However, you can also handle a requirement like this in a PIP, in which case you do not need any changes to XACML.
>
> Given that, we could define these extensions into XACML, but I have doubts about what the value of this would be since it complicates the XACML language, making XACML harder to learn and implement. And since these operators/iterators are already available in commonly used PIP backends such as SQL and LDAP, so the XACML industry would essentially be re-inventing these features into the XACML language, although every organization already has easy access to solve these use cases using the existing XACML spec and PIPs.
>
> Best regards,
> Erik
>
> On 2012-12-17 07:43, Steven Legg wrote:
>> Hi Richard,
>>
>> On 30/11/2012 8:13 AM, Hill, Richard C wrote:
>>> 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.
>> I think Hal is on the right track but hasn't taken it far enough.
>>
>> I've encountered use cases where I need to reference attributes that 
>> are not part of the subject, but rather are attributes of some 
>> entity/object that is related to subject. For example, attributes of 
>> the organization that employs the subject, or attributes of another 
>> person, being the parent/guardian of the subject. The IPC and EC-US 
>> profiles have other examples of a need to reference attributes of 
>> things related to the subject or resource, but not really part of the 
>> subject or resource.
>>
>> The IPC and EC-US profiles try to shoehorn these attributes of 
>> related objects into the subject and resource categories by 
>> "flattening", but this is woefully inadequate when the relationships 
>> are one-to-many or many-to-many.
>>
>> Consider this simple example as an illustration. I want to indicate 
>> that the subject is an employee of Ajax Inc, a commercial 
>> organization, which is a customer of Widget Inc., a non-profit 
>> organization and also the IP owner.
>> The subject is also a contractor to Widget Inc. The IPC profile would 
>> have me create a request context something like this (from here on 
>> I've shortened all the URIs to just the last part and removed the 
>> IncludeInResult XML attributes in the interest of readability):
>>
>> <Attributes Category="access-subject">
>>    <Attribute AttributeId="subject-to-organization-relationship">
>>      <AttributeValue DataType="anyURI">employee</AttributeValue>
>>      <AttributeValue DataType="anyURI">contractor</AttributeValue>
>>    </Attribute>
>>    <Attribute AttributeId="organization">
>>      <AttributeValue DataType="string">Ajax Inc.</AttributeValue>
>>      <AttributeValue DataType="string">Widget Inc.</AttributeValue>
>>    </Attribute>
>>    <Attribute AttributeId="organization-type">
>>      <AttributeValue DataType="anyURI">commercial</AttributeValue>
>>      <AttributeValue DataType="anyURI">non-profit</AttributeValue>
>>    </Attribute>
>>    <Attribute AttributeId="business-context">
>>      <AttributeValue DataType="anyURI">customer</AttributeValue>
>>    </Attribute>
>>    <!-- Other subject attributes here. --> </Attributes> <Attributes 
>> Category="resource">
>>    <Attribute AttributeId="ip-owner">
>>      <AttributeValue DataType="string">Widget Inc.</AttributeValue>
>>    </Attribute>
>>    <!-- Other attributes of the resource. --> </Attributes>
>>
>> The "flattening" process makes the request context ambiguous and 
>> leaves policy evaluation open to false-positive and false-negative 
>> results. Which organization is the subject an employee of ? Is it 
>> both ? Which organization is commercial and which is non-profit ? 
>> There's no way to tell from the request context.
>>
>> The real world allows objects of many kinds that can be related to 
>> each other in many ways. To capture that reality, XACML needs the 
>> ability to represent a request context that is a graph of objects, 
>> rather than a small list of predefined categories. If I reinterpret a 
>> category as an object (i.e., a list of attributes) and use attribute 
>> values of the anyURI data-type as references between objects, then I 
>> can turn the request context into a graph without changing the syntax 
>> at all. Having a predetermined category URI isn't adequate when there 
>> is a need to represent multiple instances of the same kind of object, 
>> as Erik points out. The answer is to decouple the kind of a object 
>> from the category URI by regarding the category URI as simply a 
>> unique identifier for a distinct object. These URIs could be 
>> anything, e.g., UUIDs, LDAP URLs, OID URNs, or whatever. The 
>> predefined category URIs become well known aliases for singling out 
>> the particular objects that are significant to the access attempt, e.g., the subject and resource.
>> These objects are the entry points into the graph.
>>
>> If I break out the different entities and relationships into separate 
>> <Attributes> elements and use anyURI values to link them, then I get 
>> a request context that looks like this:
>>
>> <Attributes Category="access-subject">
>>    <Attribute AttributeId="relationship-ref">
>>      <AttributeValue DataType="anyURI">relationship-1</AttributeValue>
>>      <AttributeValue DataType="anyURI">relationship-2</AttributeValue>
>>    </Attribute>
>>    <!-- Other subject attributes. --> </Attributes> <Attributes 
>> Category="relationship-1">
>>    <Attribute AttributeId="subject-to-organization-relationship">
>>      <AttributeValue DataType="anyURI">employee</AttributeValue>
>>    </Attribute>
>>    <Attribute AttributeId="organization-ref">
>>      <AttributeValue DataType="anyURI">organization-1</AttributeValue>
>>    </Attribute>
>> </Attributes>
>> <Attributes Category="relationship-2">
>>    <Attribute AttributeId="subject-to-organization-relationship">
>>      <AttributeValue DataType="anyURI">contractor</AttributeValue>
>>    </Attribute>
>>    <Attribute AttributeId="organization-ref">
>>      <AttributeValue DataType="anyURI">organization-2</AttributeValue>
>>    </Attribute>
>> </Attributes>
>> <Attributes Category="organization-1">
>>    <Attribute AttributeId="organization"
>>      <AttributeValue DataType="string">Ajax Inc.</AttributeValue>
>>    </Attribute>
>>    <Attribute AttributeId="organization-type">
>>      <AttributeValue DataType="anyURI">commercial</AttributeValue>
>>    </Attribute>
>>    <Attribute AttributeId="business-context-ref">
>>      <AttributeValue DataType="anyURI">business-context-1</AttributeValue>
>>    </Attribute>
>>    <!-- Other attributes of organization "Ajax Inc." here. --> 
>> </Attributes> <Attributes Category="business-context-1">
>>    <Attribute AttributeId="business-context">
>>      <AttributeValue DataType="anyURI">customer</AttributeValue>
>>    </Attribute>
>>    <Attribute AttributeId="organization-ref">
>>      <AttributeValue DataType="anyURI">organization-2</AttributeValue>
>>    </Attribute>
>> </Attributes>
>> <Attributes Category="organization-2">
>>    <Attribute AttributeId="organization"
>>      <AttributeValue DataType="string">Widget Inc.</AttributeValue>
>>    </Attribute>
>>    <!-- Other attributes of organization "Widget Inc." here. --> 
>> </Attributes> <Attributes Category="resource">
>>    <Attribute AttributeId="ip-owner">
>>      <AttributeValue DataType="anyURI">organization-2</AttributeValue>
>>    </Attribute>
>>    <!-- Other attributes of the resource. --> </Attributes>
>>
>> The affiliation of the subject to an organization is represented by 
>> an object (<Attributes> element) containing the 
>> subject-to-organization-relationship
>> attribute. The relationship of one organization to another is 
>> represented by an object containing the business-context attribute.
>> Each of the organizations is represented by an object containing the 
>> organization attribute.
>> Note that
>> relationship-1, relationship-2, organization-1, organization-2 and
>> business-context-1 are not predefined URIs. I'm using them as 
>> placeholders for UUIDS, or something similar, that uniquely identify 
>> each object.
>>
>> With the above request context I am able to faithfully represent the 
>> situation I originally expressed in English. I don't expect that the 
>> PEP would actually provide a request context like this. More likely, 
>> the context handler would construct the request context on demand by 
>> querying a PIP, given a bare-bones subject and resource provided by 
>> the PEP as a starting point.
>>
>> The next thing I need to address is how a graph-like request context 
>> can be evaluated by policies.
>>
>> The first thing to note is that attribute designators use 
>> predetermined URIs for the category, but most of the graph objects 
>> have URIs that won't be known at the time a policy is written, and 
>> may vary over time. To overcome that I need an attribute designator 
>> in the form of a function so that I can feed into it the URI values 
>> fetched by other attribute designators.
>>
>> So an attribute designator like this:
>>
>>      <AttributeDesignator
>>        Category="access-subject"
>>        AttributeId="relationship-ref"
>>        DataType="anyURI"
>>        MustBePresent="false"/>
>>
>> is equivalent to an attribute-designator function:
>>
>>      <Apply FunctionId="attribute-designator">
>>        <AttributeValue DataType="anyURI">access-subject</AttributeValue>
>>        <AttributeValue DataType="anyURI">relationship-ref</AttributeValue>
>>        <AttributeValue DataType="anyURI">anyURI</AttributeValue>
>>        <AttributeValue DataType="boolean">false</AttributeValue>
>>      </Apply>
>>
>> Each of the arguments, especially the first one, is able to be an 
>> arbitrary expression instead of a constant.
>>
>> The attribute-designator function isn't enough by itself. To do 
>> really interesting things with the graph I find I also need to invoke 
>> the iterator expressions I described on the comment list some time ago:
>> https://lists.oasis-open.org/archives/xacml-comment/201101/msg00007.h
>> t
>> ml
>>
>> Armed with the attribute designator function and the ForAny 
>> expression I can apply conditions to any part of the graph. For 
>> example, if I want to test whether the subject is an employee of the 
>> IP owner I could use this
>> expression:
>>
>> <ForAny VariableId="$a">
>>    <!-- $a is bound to each relationship-ref URI in turn -->
>>    <AttributeDesignator
>>      Category="access-subject"
>>      AttributeId="relationship-ref"
>>      DataType="anyURI"
>>      MustBePresent="false"/>
>>    <Apply FunctionId="and">
>>      <!-- Return true if and only if the 
>> subject-to-organization-relationship of
>>           the relationship object referenced by $a contains the value 
>> "employee". -->
>>      <Apply FunctionId="anyURI-is-in">
>>        <AttributeValue DataType="anyURI">employee</AttributeValue>
>>        <Apply FunctionId="attribute-designator">
>>          <VariableReference VariableId="$a"/>
>>          <AttributeValue
>> DataType="anyURI">subject-to-organization-relationship</AttributeValue>
>>          <AttributeValue DataType="anyURI">anyURI</AttributeValue>
>>          <AttributeValue DataType="boolean">false</AttributeValue>
>>        </Apply>
>>      </Apply>
>>      <!-- Return true if and only if the organization referenced by 
>> the relationship
>>           object referenced by $a is the IP owner. -->
>>      <Apply FunctionId="anyURI-at-least-one-member-of">
>>        <Apply FunctionId="attribute-designator">
>>          <VariableReference VariableId="$a"/>
>>          <AttributeValue
>> DataType="anyURI">organization-ref</AttributeValue>
>>          <AttributeValue DataType="anyURI">anyURI</AttributeValue>
>>          <AttributeValue DataType="boolean">false</AttributeValue>
>>        </Apply>
>>        <AttributeDesignator
>>          Category="resource"
>>          AttributeId="ip-owner"
>>          DataType="anyURI"
>>          MustBePresent="false"/>
>>      </Apply>
>>    </Apply>
>> </ForAny>
>>
>> For the record, the answer is false for the graph request context I 
>> provided above. The current profile with "flattening" is incapable of 
>> such precision.
>>
>> I would expect to write up the graph-like request context, the 
>> attribute designator function and iterator expressions as a separate 
>> profile since they are generally useful beyond just the IPC profile.
>>
>> Regards,
>> Steven
>>
>>> - 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
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: xacml-help@lists.oasis-open.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org

Attachment: IPC.pdf
Description: IPC.pdf