[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] On attributes of relations and SQL profile
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.
On 2013-01-31 02:45, Mohammad Jafari wrote: