Hi,
Yes, or like Steven said, that the PDP can pass fragments of the
policy to external components for evaluation. Like you said, this
effectively will cause the PDP to optimize the execution in
runtime so it corresponds to the "PIP approach" I suggested in the
initial discussion of the IPC profile.
The language should be such that this can be done efficiently. Not
sure about the details there though, but there might be XACML
functions which are not easily translatable to SQL/LDAP/whatever.
Best regards,
Erik
On 2013-02-01 19:50, Mohammad Jafari wrote:
Hi Erik,
I agree that
the performance becomes an issue when the dataset in the
table-attribute is very large. To solve this problem,
additional query restrictions can be added to the
“AttributeSelector/Designator” to pass some initial
filtering criteria to PIP to get a smaller table. This
actually brings my solution and yours close to each other:
Large data sets will be avoided by filtering from source (on
the PIP side) but the PDP still has the control over the
filtering and the XACML policy can keep track of all the
logic in the policy.
Regards,
Mohammad
From:
Erik Rissanen [mailto:]
Sent: Thursday, January 31, 2013 3:45 AM
To: Mohammad Jafari
Cc:
Subject: Re: [xacml] On attributes of relations
and SQL profile
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>
