[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [xacml] decision combining algorithm: EntireHierarchy or arbitrary resource list
I can imagine that there are some pretty different use cases where it is helpful to combine the individual responses into a global decision response. I will try to give an example: Scenario 1: aggregated response Assume that it is the PEP's intended behaviour is to return an access-denied message to the user when one of the individual decision responses (send from the PDP to a remote PEP) is deny. In this case there are two better alternatives: 1) The PDP stops processes individual decision requests as soon as the first decision response is deny and gives back a global deny decision response to the user. Here the PEP will use scope=Entire-Hierarchy 2) The PDP processes all individual decision requests and combines the individual decision responses and just submits one answer to the remote PEP Evaluation Scenario 1: - Maybe this is the way to follow, if you just want to find out if the web service response as a whole is accessible or not. - Scenario 1 might not be a good solution if users request a lot of data and just a few objects are access restricted. E.g. ask for all books in a library and only some very secret books are access restricted. It might be frustrating (and server-overhead) if the user asks for books and he always gets back deny because one book in the set was access restricted. Scenario 2: individual responses Now assume that the PEP wants to control access on an intercepted web service response. In order to provide filtering the PEP will use a scope value=Descendants. In case that some nodes in the web service response are access restricted the PEP will get some individual decision responses with value deny. The PEP than performs the filtering step. This means that the PEP will delete all the access restricted nodes in the web service response. These nodes can be identified by the PEP through the resource-id values of the individual access decision response that returned deny. Afterwards the filtered web service response will be forwarded to the user. Thus he will get the intersection of requested and accessible objects and maybe a notification that his request was changed due to insufficient access rights. Evaluation Scenario 2 : - Scenario 2 might e.g. be the way to go if you sell data and the user just paid for a certain subset. He will know that he got what he paid for and will also know that there is more data he could get if he pays more. Scenario 2 might not be appropriate if you operate with highly sensitive data. Returning the intersection of requested and accessible information can already be valuable information to the user. By making clever requests he could find out some details about the access restricted data. Note that not telling the user that access restricted nodes were filtered out is not always possible. E.g. a user wants to dig a hole and asks for pipeline objects and some access restricted pipelines are not shown on his map (without notification) so he starts digging :-( Scenario 1 and 2 show that both cases A) ask for individual responses and B) ask for a global response. can be needed. The next question is why should one define rules referring to individual nodes if he just wants a global response. Reason 1: You define the same rule semantics for scenario 1 and 2 and depending on the user you choose between one of the scenarios. It is inconvenient to define nearly the same rules just because you will do different things with the decision responses) Reason 2: Even if you want to follow scenario 1 there can be the need to submit individual decision requests. Note that this contradicts your statement that... " There is no need to break the resource into individual pieces, make a decision on each one, and combine them to issue a single decision." Let me try to demonstrate through an example why this is the case. Assume this situation: 1. You like to follow Scenario 1 (aggregated response) 2. you have the following data in your context element of category resource <Person> <Location> <point>...a coordinate tupel for NY-city...</point> </Location> <YearOfBirth>1978</YearOfBirth> </Person> <Person> <Location> <Point>...a coordinate tupel for L.A...</Point> </Location> <YearOfBirth>1930</YearOfBirth> </Person> You are further trying to deny access to the person data element (and descendants) if the Person is born after 1970 and is living in California. In a GeoXACML rule the test logic is as follows: -assuming you use e.g. scope =entire-Hierarchy (i.e. individual requests will be derived and the response will be aggregated) <rule effect=deny> <Target> reg-exp-string-match(resource-id, /person[\d]) or the xpath-node-match equivalent: xpath-node-match(resource-id, /person) </Target> <condition> <apply FunctionId=and> <apply FunctionId=integer-bigger-than> <AttributeSelector RequestContext="AttributeDesignator(resource-id)+/YearOfBirth/text()> <AttributeValue>1970</AttrinuteValue> </apply> <apply FunctionId=within> <AttributeSelector RequestContext="AttributeDesignator(resource-id)+/Location/*> <AttributeValue> <Polygon> ... coordinates representing the area of CA ...</Polygon> </AttributeValue> </apply> </apply> </condition> </rule> Following this rule, the access decision for the persons data will be permit (as intended). No let's have a look at a wrong implementation of this rule that tries to see the resource (the two person objects as a whole) -and thus doesn't need the derivation of individual decision request. <rule effect=deny> <Target/> <condition> <apply FunctionId=and> <apply FunctionId=anyOf> <Function FunctionId=integer-bigger-than> <AttributeSelector RequestContext="/person/YearOfBirth/text()> <AttributeValue>1970</AttrinuteValue> </apply> <apply FunctionId=anyOf> <Function FunctionId=within> <AttributeSelector RequestContext="/person/Location> <AttributeValue> <Polygon> ... coordinates representing the area of CA ...</Polygon> </AttributeValue> </apply> </apply> </condition> </rule> This wrong implementation will wrongly result in access decision deny. The reason for the probs in the later approach is that you can't fix the evaluation on a certain context node. Further notes: - Things like in the example can't be done within xpath as xpath is not extensible (within is not supported in xpath predicates) but xacml luckily is. - Similar probs occure if you want to base a rule on a node that has child elements of the same type and your conditions refer to childs of these child nodes. Hope that these explanations help. From my point of view under the open issues the issue of aggregating results is from of secondary importance. I would further say that the aggregation step is maybe not the most common use case but a feature which is nice to have. In order to allow more flexible aggregation I would recommend to use a new xacml attribute aggregate with a value that name a xacml combining algorithm. Best regards and a lovely day jan -----Ursprüngliche Nachricht----- Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com] Gesendet: Donnerstag, 22. Oktober 2009 19:52 An: XACML TC Betreff: [xacml] decision combining algorithm: EntireHierarchy or arbitrary resource list Can anyone produce a use case that requires the decision-combining algorithm (and implied business scenario) described in MR profile section 3? By "implied business scenario" I mean something like this: 1. Policy writer creates individual rules for resources without any concern for the hierarchical context in which those resources might appear. 2. Client application sends a hierarchical resource and asks PDP for a decision that boils down to "are all of these permitted", or "are any of these denied". The hierarchical nature of the resource is irrelevant in this scenario--the "resource" could just as well be a bag of unrelated resources. Now, if the rules depend on the hierarchical relationships within the resource, it is a different matter. But in that case the ruleset itself is able to issue a single decision based on hierarchical characteristics of the resource, considered as a whole. There is no need to break the resource into individual pieces, make a decision on each one, and combine them to issue a single decision. I ask this because we should establish the need for this feature before considering whether and how to extend it to include other groups of individual resources (e.g., Children, or arbitrary xpath node selections). It is an interesting question, but in an abstract sense that is pretty far removed from core XACML use cases. In full generality, the proposal is to enable the request context to ask that the PDP make a number of individual decisions on a specified set of resources (why not actions, subjects as well?), and then combine the decisions by some predictable algorithm, and return a single decision. But to address the practical use case that Jan is proposing, I do not believe this is the right approach. Regards, --Paul --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]