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] On attributes of relations and SQL profile


Hi Erik,

 

I think eventually (and this is not restricted to this particular case and type of policy), it is a design choice where to put the logic. Pushing the logic back to the PIP blackbox makes the XACML policy simpler, but part of the logic will be concealed and hard-coded somewhere like in the Java code in your example.

 

The extreme case would be to move the entire policy logic to the PIP and have only one attribute “accessIsAllowed” in the request whose value is decided by the PIP and is used by the PDP to – ceremonially—make a decision.

So, I think, in general, it is up to the designer to decide what parts of the policy logic must reside at the PDP and what parts must be hard-coded it in the PIP backend.

 

Nonetheless, regardless of this design decision, I believe XACML must support expressing such policies for use-cases and applications that want this kind of decisions to be made via a flexible and configurable XACML policy.

 

Regards,

Mohammad

 

From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Erik Rissanen
Sent: Wednesday, January 30, 2013 8:56 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] On attributes of relations and SQL profile

 

Hi Mohammad,

I agree with you that if we are going to go into this direction and support something like this in the language itself (which has some merits) rather than off-loading it to a PIP, it makes sense to do something similar to relational databases, since an implementation can in many cases do a simple 1-to-1 translation into a database product.

However, I do think that some architectural changes are also required, not just the schema. I suspect that it will not be feasible to perform this kind of processing at the PDP side because I suspect there will be cases in which the relations will contain many rows, and it would imply large data transfers to the PDP to perform these operations on the PDP. For the iterator approach it would also imply large cross products to iterate over, in contrast to join operations on indexed tables.

This is what I tried to demonstrate with my attribute of relations code sample post, but Steven seems to have shown that this is not the case at least in the example I did. I have not read his response in detail yet. I will do so and see if I can tweak it to create a bad situation for the iterator approach. Similarly, I'll digest your proposal as well and I'll try to break it too. ;-)

(Don't get me wrong. I would be happy to see a working solution to this problem, but I am not yet convinced it can be done on the PDP. )

Best regards,
Erik


On 2013-01-24 20:31, Mohammad Jafari wrote:

I think the issue of “attributes of relations” can be summarized as the need to extend the expressive power of XACML to support:

a)      “attributes of attributes”, such as: “subject.role.issuer” (the issuer of the attribute “role” for “subject”), “resource.owner.user-id” (user id of the owner of the resource), etc.,

b)      “attributes of multiple attributes/entities”, such as: “(subject,resource.owner).friend.since” (how long the subject has been friends with the owner of the resource), and

c)       Corresponding “bag” operators.

 

My original point was that probably in next versions of XACML we can consider extending the schema so that instead of flat attributes (i.e. only one level of attributes over the main categories) more complex structures of attributes can be supported (see this email and the follow-ups).

 

While my original suggestion was a data model with hierarchical structure for attributes, another alternative is to support tuples and relations in a relational-database-like data model. This has the benefit of matching the existing database data model which is most likely what is used to store complex attributes. Although it was mentioned on the list that we may not want to re-invent SQL because of the complications, I think supporting an SQL-like functionality in XACML is straightforward and does not require extensive changes to the schema, since from a relational algebra point of view, SQL can be thought of as a collection of functions over the data type “relation”, so basically we need to define some new data types and functions. So, a SQL profile requires:

-          A new data type Tuple which is a vector (an ordered set) of attributes. A Relation is a bag of Tuples with the constraint that the data types of the attributes in all of the tuples must be consistent (this is a dynamic constraint but we already have a  similar constraint for bags of plain attributes, i.e. that all the attributes in a bag must be of the same type).

-          A set of relational functions to operate on Relations, e.g. Selection, Projection, Cartesian Product, etc. Note that the format for such functions is slightly different from the existing XACML functions, since for example, Selection requires a condition as an input. We also need a mechanism to refer to a specific attribute within the tuple for such functions. In the following example I have used the XACML “Condition” for the former case, and “TupleAttributeDesignator” for the latter.

 

Back to the IPC example from Erik’s earlier email, the condition in the policy rule and the request will look like the following (A:attribute, AV: AttributeValue, DT: DataType).

 

 

Request:

<Request>

  <Subject>

   <A Id="subject:id" DT="string">

    <AV>Alice</AV>

   </A>

   <A Id="Subscriptions" DT="tuple">

    <AV>

     <A Id="Device" DT="string">

      <AV>iPhone</AV>

     </A>

     <A Id="Location" DT="string">

      <AV>US</AV>

     </A>

    </AV>

   </A>    

   <A Id="Subscriptions" DT="tuple">       

    <AV>

     <A Id="Device" DT="string">

      <AV>XBOX</AV>

     </A>

     <A Id="Location" DT="string">

      <AV>EU</AV>

     </A>

    </AV>

   </A>

  </Subject>

  <Resource>

   <A Id="resource:id" DT="string">

   <AV>some tune</AV>

  </Resource> 

  <Action>

   <A Id="action:id" DT="string">

   <AV>play</AV>

   <A Id="action:device-context" DT="string">

   <AV>iPhone</AV>

  </Action>

  <Environment>

   <A Id="environment:location" DT="string">

   <AV>EU</AV>

  </Environment>

</Request> 

 

Condition:

<Condition FunctionId="integer:greater-than">

  <Apply FunctionId="tuple-bag-size">

    <Apply FunctionId="relation:where">

     <Condition FunctionId="and">

      <Apply FunctionId="string-equal">

       <TupleAttributeDesignator Id="Location" DT="string" />

       <Apply FunctionId="string-one-and-only">

        <EnvironmentAttributeDesignator Id="environment:location" DT="tuple"/>

       </Apply>

      </Apply>

      <Apply FunctionId="string-equal">

       <TupleAttributeDesignator Id="Device" DT="string" />

       <Apply FunctionId="string-one-and-only">

        <ActionAttributeDesignator Id="action:device-context" DT="tuple"/>

       </Apply>

      </Apply>

     </Condition>

     <SubjectAttributeDesignator Id="subscriptions" DT="tuple"/>    

    </Apply>

   </Apply>

   <AV DT="integer">0</AV>

</Condition> 

 

 

 



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