This is a Fedora Policy Enforcement Point (PEP) implementation. This PEP compiles request and environment information into an authorization request that is passed to a XACML policy decision point (PDP).
- Policies and PolicySets are stored inside Fedora (in a dedicated ModeShape workspace)
- Administrators may create separate realms of XACML policy at any point within a repository tree. For instance a collection of scientific data may have different roles or access rules than a collection of PDFs.
- Any object in the Fedora repository tree may be linked to a PolicySet, which then defines the effective policies for the subtree until another link overrides the PolicySet.
- see JCR 2.0 16.3 and JBossLDAPPolicyLocator as an example
- ?? Standard and customized XACML attribute mappings could be stored in the repository. (JCR query, data type, attribute ID)
- Write an "attribute finder" based on relative JCR XPath.
- ModeShape Question: How best to store policies within the repository? (normal nodes/properties or possibly behind the AccessManager API)
Option: Internal PDP vs. External
- Use JCR API for attribute lookups
- Always store as much as possible in the repo itself. (A. Soroka)
- Less penalty for light authZ requests (i.e. use more attribute lookups based on Fedora object model)
| 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. |
