Page History

...

This includes how policies are stored in the repository and how they are linked with content objects.

Proposed

A top-level "fedora-policy" nt:folder node holds a flat list of referenceable policies and policy sets, as nt:file nodes with XACML XML. Some of the policy sets will contain internal ID references to other policy sets and policies in the folder.

One policy set in this workspace will be configured in the XACML Policy Finder Module as the default policy, which is the policy set that is effective at the root of the Fedora/ModeShape node tree. This default policy must contain an empty target element, therefore it must be applicable to all access evaluations.

Any fcr:resource node may set a property "policy" which makes a strong reference to a single policy node. This overrides the effective XACML policy for itself and child nodes. This action requires administrator levels of access, as determined by the effective policy, or by use of a login with the fedoraAdmin role.

The Fedora XACML Policy Finder Module will implement XACML Policy Finder Module and retrieve the policy that is in scope for a given context node. It will search the tree for the closest parent with a policy property and return that XACML. It will also resolve internal URI references between policies at the request of the PDP, looking in the policy folder to find policies that are referenced in other policies.

• ROOT
  • collection A
    • policy property (REFERENCE to policy A)
  • policies
    • default policy set (XACML policy set links to B and C)
    • policy set A (nt:file, referenceable) (XACML policy set XML links to default and D)
    • policy B
    • policy C
    • policy D

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 want to resolve a single policy or policy set for a given node.

Issues

See JCR 3.8.2 Referential Integrity. It would be nice if referential integrity could be enforced for the default policy, in addition to the separately linked policies. However, my understanding is that the root node cannot have properties like this. Any ideas?

Any ideas for how to preserve referential integrity of the internal policy ID references within the XACML? Is this worth doing?

On a related note, is there any utility in doing policy-set definitions more formally as nodes linked by properties, i.e. without XML? The target section would always be empty, such that it can be used for all requests. This would add ref integrity to the graph of policies. It could be worth exploring.

How to Map XACML Attributes to Repository Data

...