Hi,
Yes, I agree with that doing it like this hides things from the
XACML policy, but that does not necessarily mean that it is not
visible from the point of view of the whole system. By including
the database queries in your "view" you still get the full
picture. Sure, it would not be standardized, so there clearly is a
case for standardizing something for handling relations, but I
have concerns about the current proposals.
My initial concern is how much of this work is going to be
re-inventing relational databases. Maybe it's not as bad as I
thought initially. But there is already a very large set of
knowledge and products out there in the database world which
easily solves this problem.
Another concern is performance since the data sets can be quite
large, so it is infeasible to transfer them into the PDP for
processing. The proposals which were being presented did not
consider this, though Steven in his latest email says that his
proposal can be optimized in this manner.
One way this can be done is by behind the scenes converting the
relational expressions into the "accessIsAllowed" form. But this
requires that the relational feature set of XACML is similar to
commonly available databases, so there is a translation algorithm.
For the iterator approach, I guess the variables convert into
column names in joins, so it might work. Regarding the nested
attributes approach, I have not thought about it yet.
One more concern I have is that, at least the iterator approach,
appears hard to work with. At least for me it takes a quite bit of
mental effort to understand the examples which have been posted to
the list. I am not sure if it is the representation or the
solution fundamentally which is causing this. Maybe it's just me
being slow minded? ;-)
If we are going to do something on this, I think the solution
should at least:
- Be easy to understand and work with. (As far as possible)
- Have an architecture which is designed to facilitate remote
execution of the relationship processing since it will not scale
to large data sets otherwise.
- Be possible to optimize in an implementation, perhaps by having
a form which is easy to transform to SQL in the implementation.
- Be of a form which is not too powerful (for instance Turing
complete), so it can be processed by automatic analysis tools for
visibility purposes.
- Also see if we can use an existing solution rather than
inventing something of our own.
Best regards,
Erik
On 2013-01-31 02:45, Mohammad Jafari wrote:
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:
[mailto:]
On Behalf Of Erik Rissanen
Sent: Wednesday, January 30, 2013 8:56 AM
To:
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>
