This is an implementation of the authorization delegate API. This PEP compiles request and environment information into an authorization request that is passed to a XACML policy decision point (PDP).
Requirements (proposed):
- Authoring XACML policies is an involved technical process, with behavior hinging upon the total policy set. For this reason policies/sets will be centralized, named and reused as much as possible. (Less is more)
- Administrators may choose to enforce a different set of XACML policies at any point within the repository tree.
- Metadata properties, such as ACLs or rights statements, can be used to avoid authoring more XACML.
- Node properties can determine the relevant policy within a set and the outcome from within that policy.
- Policies may depend upon an access role attribute.
- Policies (and/or sets of them) must be stored in the repository.
- Policies must be enforced on externally managed content, i.e. projected nodes within a federated node. (inc. filesystem connector)
Design Notes:
- Constructing a policy set for the JBOSS engine:
- see JCR 2.0 16.3 and JBossLDAPPolicyLocator as an example.
- Need to map XACML attributes to the repository, given a context node.
- JCR query or XPath?
- How to determine XACML data type?
- Can we write a extensible "attribute finder" based on relative JCR XPath?
- Should we implement a local or remote PDP?
- Should we use JBoss XACML Engine?
- APIs to look at:
- org.jboss.security.xacml.sunxacml.finder.PolicyFinderModule is used to find a policy (or policy set) that matches the request evaluation context. Also used to lookup a policy that is referenced within a policy set by ID.
- APIs to look at:
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. |