1. The wire is not defined.
2. The attributes describing the subject presented to the PDP are not cryptographically bound to a trusted identity provider (IdP).
3. The policy authoring story is way too technical.
By the first, I mean that the transport mechanism used to communicate with a PDP is not standardized. There is the SAML profile for XACML (PDF), but that's by no means enough. IMO, there needs to be many different profiles created before the protocol will reach critical mass -- a simple SOAP interface, one for JSON, OData, WS-Trust, etc., etc. Only after this happens will it become commonplace to find PEPs and PDPs from different companies communicating because custom integration work won't be required to do so. Each vendor will ship messages through a standardized and well-defined pipe.
Another problem is that the attributes that describe a subject are not cryptographically bound to a trusted IdP. According to the XACML spec, the PDP is presented with XML containing attributes that describe who the subject is. How is it supposed to know that this information is correct? Because it and the PEP are within a trusted subsystem? That's not going to cut it in many cases. Lots of times the PEP will present the PDP with information that it was given from an upstream entity, and the PDP will have to decide if access should be granted based on who asserted it. How can it do this unless the PEP provides more than strings? It can't. Crypto is needed.
The last problem with XACML is that the authoring experience of all the products on the market that I've looked at require the user to have a computer science degree and five years of software engineering experience to use them. (I'm exaggerating, but not much.) Policy authors in most organizations, I believe, are not engineers; they are business analysts and other non-technical folks.
Solutions to these Problems
First, the wire must be defined. Period. Gerry Gebel of Axiomatics said at CIS that it was his impression that the XACML technical committee (TC) has no interest in defining transport mechanisms. I really can't understand this. I would argue that this lack of definition will cause the market to view the spec as incomplete, immature, and unusable. The solution to this problem is to be at the table w/ the TC and persuade them.
The solution to the second problem is to include a digital signature computed by the IdP in the environment element of the request sent to the PDP. This way, it will be able to recompute the signature using the attributes presented by the PEP. If the PEP or any other entity between the PDP and the IdP has altered the attributes, the signature will not match, and the PDP won't allow access to the resource. How would this work in practice? I haven't thought about it enough to say, but I'm told that that's what IBM does in their XACML product.
The third problem can be solved with better authoring tools. As Anil Saldhana of Red Hat wrote last month, editors are needed that allow non-technical professionals to specify policy in the domain they are in. Using domain specific authoring tools, the policy creator won't know or care that XACML is the underlying technology. To them, it is a helpful tool that allows them to define rules that govern access to their organization's data using the nomenclature of their company and industry.
Conclusion
More Here
Courtesy:http://travisspencer.com/blog/2010/09/problems-with-xacml-and-their.html