...
When combining XACML policies into sets, you have to also specify a combining algorithm of either permit-override or deny-override. For this reason we also always want to resolve a single policy or policy set for a given node.
...
| Internal PDP (within ModeShape JVM) | External PDP (remote XACML service) |
|---|---|
Minimal administrative overhead through dependency injection, etc.. | Flexible, can be any XACML implementation |
| ModeShape cache will keep frequently used ACL metadata in memory. Removes the need for any additional cache. | Decent performance may require custom metadata caches. |
| No network overhead making connections or marshaling data. | Network latency, etc.. |
| Decision and policy cache invalidation may be based on events. | Cache invalidation requires wiring JCR or Fedora JMS specifics into the chosen XACML service. Cache invalidation would be asynchronous. |
Adds complexity to the runtime webapp – moving closer to a monolithic, coupled application. |
...
Propose Local
Local. This presents fewer obstacles in the short term and we have no use cases yet which dictate that a remote XACML PDP is needed. A local PDP makes this authz delegate easier to configure since no fedora, modeshape or SOAP XACML clients need to be set up between the separately running services. If we ever need the PDP to be remote we can do the extra plumbing to make it so.