AW: [xacml] using the xacml obligation mechanism for service request or response rewrite

["Jan Herrmann" <herrmanj@in.tum.de>]

Dear Paul,
thanks for your comments.
regarding your question:
"... but have you actually demonstrated that it would be too slow?"
no but I am pretty sure that the service or dbms will be better in
evaluating en extended request than an xacml pdp engine that tries to filter
out certain nodes in the respose. More important is the fact that with our
use cases we have various types of services and they support all kinds of
operations (e.g. delete or insert operations). so changing the example given
in the last mail to an delete request  highlights the need for the
obligation based rewrite mechanism. 

Another aspect related to the location, were to enforce obligations. If you
have obligations referring to XACML evaluation context attributes than the
pep will not have access to the attributes. thus the context handler has at
least to pre-process the obligation to dereference selectors/designators
used to instantiate an attribute in the obligation's
<AttributeAssignmentExpression>. Hence next to the argument, that
obligations should refer to the representation of the request|response in
the xacml decision request, this aspect also motivates that it should be
left open to the implementer whether obligations are "enforced" in the ctx
handler or in the pep. 
 
best regards jan


________________________________________
Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com] 
Gesendet: Freitag, 10. September 2010 00:02
An: Jan Herrmann; xacml@lists.oasis-open.org
Betreff: RE: [xacml] using the xacml obligation mechanism for service
request or response rewrite 

So, the business rule is apparently something like this:  “a user’s
attributes determine the type of records he can see”.

And you are implementing this: “a user’s attributes determine the type of
query he can make”.

You do this by rewriting the query based on obligations returned from a
XACML request.

If you were directly implementing the business rule you would filter the
query result set (perhaps by using a multi-decision XACML request).  But you
fear the performance impact of this is too great (certainly it would be
slower than the SQL query—but have you actually demonstrated that it would
be too slow?).

Here’s another option.  Instead of asking for a decision on the WS request,
ask for a decision on the WS response.  The XACML request, in human
language, would be like “can user X see a list of building records?”.  The
XACML response would come back like “Yes, but only those under 1M in
value.”  The web app would then be obligated to apply a filter to the
response to remove the restricted records—perhaps by applying an XSLT
transformation.   The performance would be worse than using a custom SQL
query, but probably better than making a multi-decision XACML request.

--Paul

From: Jan Herrmann [mailto:herrmanj@in.tum.de] 
Sent: Thursday, September 09, 2010 15:58
To: xacml@lists.oasis-open.org
Subject: [xacml] using the xacml obligation mechanism for service request or
response rewrite 

Hi all,

as promised in the last tecon below some insights in a way how to use
xacml’s obligation mechanism in SOA:

• the pep intercepts the communication between the subject und the service –
e.g an Web Service request  or response r in format x (ie. r.x)
• the ctx handler transforms the r.x and includes it a xacml decision
request in format y (ie. r.y)
• to enforce most of the access rights based on the Web service request
there is a need to rewrite the request. additionally some rights need to be
enforced through rewrite of the response. in both cases the aim behind the
rewrite is to allow the intersection of the indented interaction and the
permitted interactions
• the rewrite can be done by rewrite functions defined in obligations that
refer to r.y
• a ctx handler receiving rewrite rules transforms r.y (i.e. the
representation of the request in the evaluation context) correspondingly.
this will result in r.y’
• after the ac process the ctx transforms r.y’ back to the original format x
so you get r.x’
• the pep can choose between different options how to proceed 
• no rewrite --> forward original request | response 
• rewrite -> forward rewritten Web Service  request|response
• rewrite -> deny request, send error msg to user (optinally show him r.x’
to show him the permitted subset of his request)

Example:

request form user in string format:
r.x := 
select * 
from Building 
where owner = ’state’

request form user in xml format as included under <content> in xacml access
decision request
r.y := 
<select>
  <proj>*</proj>
  <from>
    <table>Building</table>
  </from>
  <where>owner = ’state’</where>
</select>

obligation in a rule that matches:
- subject.name = alice
- xpath-node-equal(content-selector, /select[ from/table/text() = Building])
-obligation: 
       - functionToCall = addToWhereClauseByAnd
       - argument1 = ‘price < 1,000,000’
       - optional: functionDefInEgJava = public string
 addToWhereClauseByAnd(string s){….} //this could allow for flexible
obligation-function definition and will still keep interop)

result in ctx handler after ac process:

r.y’ :=
<select>
  <proj>*</proj>
<from>
  <table>Building</table>
</from>
<where>owner = ’state’ AND price < 1,000,000 </where>
</select>

rewritten request in original sql string format:
r.x’ := 
select * 
from Building 
where owner = ’state’ AND price < 1,000,000

The rewritten request implies that the user can only access building data
 with a price less than one million. According to this solution it is very
useful to allow obligation processing in the ctx handler (which could run on
a different machine than the pep). for those that know oracles virtual
private database tech. this approach is similar but more flexible, external
from the service/dbms implementation and could be standardised
Looking forward to hear your thoughts on this solution. 

best regards 
jan
________________________________________

Jan Herrmann
Dipl.-Inform., Dipl.-Geogr. 

wissenschaftlicher Mitarbeiter

Technische Universität München
Institut für Informatik 

Lehrstuhl für Angewandte Informatik / Kooperative Systeme

Boltzmannstr. 3
85748 Garching

Tel:      +49 (0)89 289-18692
Fax:     +49 (0)89 289-18657
Raum:
www11.informatik.tu-muenchen.de
________________________________________