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


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]