When customers decide to externalize their authorization and to go for a standards-based solution, namely a XACML-based solution, they need to be extremely careful how the vendor implements XACML. It is not just about implementing XACML’s request-response protocol. It is not just about authoring policies natively in XACML. It is also about implementing in an elegant, efficient, and modular way the XACML architecture.
The latter contains several key components as listed hereafter:
1. Firstly, the Policy Decision Point (PDP): this is where policies are evaluated and a decision is reached.
2. Secondly, the Policy Enforcement Point: this is where the request is created sent to the PDP and the response received and handled. The PEP can be application-specific.
3. Thirdly the Policy Retrieval Point (PRP) and the Policy Information Point (PIP) are two key components the PDP needs to retrieve policies and retrieve attributes respectively.
The way your vendor’s PDP implementation interacts with PEP, PRP, and PIP will determine how flexible their architecture is and how costly a deployment might turn out to be both in terms of non-capital investment (professional services, human resources) and in terms of capital investment (new hardware? new software? licenses?)
You should try to aim for a light-weight and flexible vendor that can provide a modular architecture where each component (PEP, PDP, PRP, PIP) can be taken individually, ripped from the others, dropped into new environments, and adapt to new components / deployments.
There is another XACML component to be considered: the Policy Administration Point (PAP). This component should provide (a) an interface to manage XACML policies and their lifecycle and (b) a XACML-aware client to facilitate the policy-authoring task.
Again, the way the PAP interacts with the other components should be flexible and modular. One should be able to run the PAP remotely or even perhaps without some of the other components.