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

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

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