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)
- Must be able to authorize based on requesting I.P. address
- Must be able to authorize based on resource mixin types
- Must be able to authorize based on Hydra rightsMetadata datastream
- Must be able to authorize based on resource mimetype
Design Notes:
- 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 the PicketBox JBoss XACML Engine?
- PicketLink and PicketBox projects use the same XACML PDP. PicketLink is a larger umbrella project of security services.
- 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.
- org.jboss.security.xacml.sunxacml.finder.AttributeFinderModule is used to find attribute values when evaluating a policy.
- Constructing a policy set for the JBOSS engine:
- see JCR 2.0 16.3 and JBossLDAPPolicyLocator as an example.
| 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. |
