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:
erik@axiomatics.com ] Sent: Thursday, January 31, 2013 3:45 AM To: Mohammad Jafari Cc:
xacml@lists.oasis-open.org 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:
xacml@lists.oasis-open.org [ mailto:
xacml@lists.oasis-open.org ] On Behalf Of Erik Rissanen Sent: Wednesday, January 30, 2013 8:56 AM To:
xacml@lists.oasis-open.org 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>