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 Mohammad,

On 25/01/2013 6:31 AM, 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
<https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201212/msg00047.html> 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.

Why would it need to be ordered ? We access attributes by their ID and never
by their position or offset.

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

I don't see the need for this constraint unless you are planning to drop DataType
from attribute designators. Each distinct combination of category, attribute ID
and data type is a separate entity. From an XACML functional point of view, two
attributes like access-subject/foo/string and access-subject/foo/anyURI are no
more related than access-subject/foo/string and access-subject/bar/anyURI. Any
relationship is only in the mind of the beholder.

Or in other words, I don't see anything wrong with a tuple having both
access-subject/foo/string and access-subject/foo/anyURI as attributes.


-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
<https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201212/msg00057.html>, 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>

Your attributes are all single-valued. Is that an intentional restriction
or just a coincidence ?

Apart from syntactic differences, what you have presented above is the same as
the compound attribute values I described here:
https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201212/msg00053.html
A problem I noted then was that in non-trivial situations duplicates of objects
start showing up throughout the request context. Sooner or later you will need
to add identifiers to the tuples so that duplicates can be recognized. The request
context can also be infinite in theory. While I don't see any obstacles to using
embedding as a substitute for foreign keys in tuples, it doesn't look like a good
fit to the relational model that you are trying to emulate in XACML. I moved to
making the tuples objects on par with the predefined categories (i.e., not embedded)
to remove the duplication and make the request context finite. I described this
approach in my original response to Richard:
https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201212/msg00041.html .


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"///>

The syntax of this designator doesn't indicate from which tuple in which set of tuples
it is extracting the Location/string attribute. That is implied by the enclosing
"relation:where" function and its child SubjectAttributeDesignator. Consequently,
I don't see how you could express a join between two sets of tuples with this syntax.
You would need a "relation:where" function nested within another "relation:where"
function with a comparison between the outputs of a pair of tuple designators inside
the innermost "relation:where" function. There is no way for the tuple designators
to indicate whether they are extracting an attribute from the inner tuple or the outer
tuple.


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

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

Shouldn't this be DT=string ?


</Apply>

</Apply>

<Apply//FunctionId="string-equal">

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

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

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

Shouldn't this be DT=string also ?


</Apply>

</Apply>

</Condition>

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

</Apply>

</Apply>

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

</Condition>


By the way, this is how I would solve this example using the iterator expressions
and compound attribute values:

<ForAny VariableId="$a">
  <AttributeDesignator
    Category="access-subject"
    AttributeId="subscriptions"
    DataType="compound-value"
    MustBePresent="false"/>
  <Apply FunctionId="and">
    <Apply FunctionId="string-at-least-one-member-of">
      <TupleAttributeDesignator AttributeId="Location" DataType="string">
        <VariableReference VariableId="$a"/>
      </TupleAttributeDesignator>
      <AttributeDesignator
        Category="environment"
        AttributeId="environment:location"
        DataType="string"
        MustBePresent="false"/>
    </Apply>
    <Apply FunctionId="string-at-least-one-member-of">
      <TupleAttributeDesignator AttributeId="device" DataType="string">
        <VariableReference VariableId="$a"/>
      </TupleAttributeDesignator>
      <AttributeDesignator
        Category="action"
        AttributeId="device:context"
        DataType="string"
        MustBePresent="false"/>
    </Apply>
  </Apply>
</ForAny>

My version of TupleAttributeDesignator (I wouldn't actually call it that)
extracts the nominated attribute from its child argument, which is required
to be a compound-value (i.e., a tuple).

In particular, note that I didn't need to invoke the tuple-bag-size and
integer-greater-than functions.

Regards,
Steven


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