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>
