OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]