[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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] 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 ________________________________________ Raum: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]