Page History

...

• 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, such as ACLs or rights statements, can be used to avoid authoring more XACML.
  
  • Node Resource 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 may reference any value obtained via a SPARQL query, relative to the content noderesource, but the query must be mapped to a XACML attribute in configuration.
• Policies (and/or sets of them) must be stored in the repository.
• Policies must be enforced on externally managed content, i.e. projected nodes resources within a federated noderesource. (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
• Must be possible to use same rules as defined in policies in the following contexts (except for #1, we only need to demonstrate/document the possibilities):
  1. calls to Fedora REST-API
  2. calls to Fedora Java classes
  3. calls to external Solr index
  4. calls to external triplestore

...

Policy Persistence

Policy and Policy Set nodes resources may be stored in any part of the repository tree at the discretion of the administrator.

Policies and Policy Sets are referenceable fcr:datastream nodes resources that contain XACML XML.

Policy sets contain Fedora URI references to other policy sets and policies. Policy sets can define a tree structure of policies.

Policy URIs have the form info:fedora/path/to/PolicyNodePolicyResource. These URIs are the IDs of the Policies and PolicySets in the XACML datastream.

...

One policy set in the workspace will be configured (in the XACML Policy Finder Module) as the default policy for the workspace. This is the same as saying that this default policy set is effective at the root of the Fedora node resource tree and everywhere else unless overridden.

Any fcr:resource node may set a property policy which makes a strong reference to a single policy or set noderesource. This overrides the effective XACML policy for itself and child nodesresources. 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 Policy Finder implements the JBoss XACML PolicyFinderModule interface. It retrieves the policy or set that is effective for a given context noderesource, and searches the tree for the closest parent with a policy property and returns that XACML. It also resolves internal URI references from policy sets at the request of the PDP, looking in the workspace by policy URI.

...

When Modeshape checks for permission to remove a node resource and the authz delegate returns true, there are no followup checks for removal of the child nodesresources. The children (and their children, etc) are deleted along with the parent, but the AuthZ Delegate gets no permission callback for them.

...

Fedora will need an implementation of this interface, originally part of Sun XACML. This finder module will deliver the correct policy set for the resource ID in a XACML request context according the rules for "Finding the Effective Policy Set" above. A similar kind of lookup, based on node resource path, happens in the access roles provider.

...

The policy lookup operation involves the following steps:

1. finding the nearest real node resource for a given the path, since access checks are sometimes performed on new nodes resources before they are added.
2. Then you find the nearest parent with a policy property.
3. Then you read in and return the policy XACML. (There is a PolicyReader class you can use here)
4. It will also need to support requests for policies by node resource URI, i.e. resolving policies that are linked from the first policy.

...

Implements callback methods for finding child and descendant resources. This is used for delete and possibly move operations, which have cascading effect on the node resource tree.

AttributeFinderModule(s)

...

These finder modules retrieve information about the node resource which is being accessed. They should be implemented as several finder modules for clarity.

A triple finder module resolves attribute IDs (URIs) to RDF properties on fedora resources. Attributes are not configured in advance. XACML authors may reference any URI and if there is one or more triple with the correct subject node resource and predicate, then the resource will be returned. It should match the data type expected in XACML, which is also part of the arguments passed to the finder module.

A SPARQL finder module retrieves data indirectly linked to the subject noderesource. This finder module will resolve attributes via a configured map of attribute IDs to SPARQL queries.

...

• PolicySetId identifiers will be URIs of the form info:fedora/policies/PolicyNodePolicyResource.  This identifier will be resolvable to the path to the policy resource in the repository.

• Internal policy element identifiers for the XACML elements PolicyId and RuleId will have the urn prefix fcrepo-xacml.