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