Re: [xacml-users] retrieving a list or query filter of resources the caller is authorized for

[Oleg Gryb <oleg_gryb@yahoo.com>]

>Of course you must always do some work to implement a system, but what
>is "a lot"?.

"A lot" is when the code that you write in PIP and PEP is much bigger than the policy itself. Yes, there is a goodness in simplifying, formalizing and externalizing authz rules, but the code outside the PDP engine can undermine it. 

PDP's Response/Request and Policy syntax are defined well. Semantics  of some syntax constructs and rule evaluation logic are still discussed in this forum often, which means that they are probably not defined as well as syntax.

PIP and PEP are just concepts and this is a real threat for somebody who relies on reviewing policies only when tries to assess a reliability of XACML-based authz solution.




----- Original Message ----
From: "Tyson, Paul H" <PTyson@bellhelicopter.textron.com>
To: Oleg Gryb <oleg@gryb.info>; Yoichi Takayama <takayama.yoichi@gmail.com>
Cc: Ralf Lorenz <rol@mms-dresden.de>; xacml-users@lists.oasis-open.org
Sent: Fri, April 16, 2010 10:48:14 AM
Subject: RE: [xacml-users] retrieving a list or query filter of resources the caller is authorized for



> -----Original Message-----
> From: Oleg Gryb [mailto:oleg_gryb@yahoo.com] 
> Sent: Friday, April 16, 2010 10:37
> To: Yoichi Takayama
> Cc: Tyson, Paul H; Ralf Lorenz; xacml-users@lists.oasis-open.org
> Subject: Re: [xacml-users] retrieving a list or query filter 
> of resources the caller is authorized for
> 
> 
> Ralf's use case provoked me to express some thoughts that you 
> might not agree with,  but,  I think, they are important for 
> somebody who tries to use XACML in their business applications: 

As somebody who has actually used XACML in a major business application,
I must disagree with some of these points.

> 
> 1. XACML - is not a complete, ready to use authorization 
> solution, it's rather a brick, maybe even a corner stone, in 
> your authz solution.

We found it to be very well-developed, conceptually and practically.
You just have to supply rules and attributes.

> 2. XACML practical value is very limited in many cases 
> without PIP and PEP that are defined at conceptual level only.

Attribute provisioning via a PIP is required if your PDP must respond to
requests that are not fully attributed.  The problems to overcome here
are messy enterprise ontologies and multiple (possibly conflicting) data
sources.  But the difficulties are due to the environment, not to any
shortcomings in the XACML specification.  Likewise with PEPs--most COTS
applications have internal authorization systems that do not allow
external rules or decision-making.  The problem is with the
applications, not XACML.

> 3. In many cases you need to do a lot of plumbing around PEP 
> and PIP to meet your business requirements.

Of course you must always do some work to implement a system, but what
is "a lot"?.  In our experience it was very easy to modify a major
in-house web app to implement a PEP.  Customizing vendor apps can be
much more difficult, as is persuading them to build in PEPs.  PIPs can
be implemented very simply by tapping into existing databases with a
jdbc app.

The XACML request/response language, policy language, and policy
evaluation process are well-defined, so nothing prevents vendors from
supplying XACML-friendly applications, or consumers from specifying
these capabilities.

> 4. XACML Policies are very rigid and lack dynamics of a 
> programming language, thus you need to write your custom code 
> somewhere else (e.g. in PEP and PIP services).

Some of this is goodness, because this makes it easier to analyze
policies and predict their results.  XACML 3.0 adds dynamic return
values in Obligations and Advice, and extends the usefulness of XSLT for
writing rules about XML resources.  In our experience writing a
moderately complex policy set we lacked nothing except a
string-equal-ignore-case function (which was added in 3.0).

Regards,
--Paul