...
- 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):
- calls to Fedora REST-API
- calls to Fedora Java classes
- calls to external Solr index
- calls to external triplestore
...
This includes how policies are stored in the repository and how they are linked with content objectsresources.
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 will 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.
NICE TO HAVE: Referential integrity between policy sets and policies will be maintained via a ModeShape Sequencer. It will maintain a set of REFERENCE properties on the policy set noderesource, pointing to the policy nodes resources mentioned in XACML. This will prevent any policies still referenced from being deleted.
...
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 Locator will implement the Policy Locator interface. It will retrieve the policy or set that is effective for a given context noderesource. It will search the tree for the closest parent with a policy property and return that XACML. It will also resolve internal URI references from policy sets at the request of the PDP, looking in the workspace by policy URI.
...
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 resource cannot have properties like this. Any ideas?
...
On a related note, is there any utility in doing policy-set definitions more formally as nodes resources 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. Such policy set nodes resources would use properties to link to their constituent policies and to specify the combining algorithm. (They could be converted to XACML by our policy finder module on their way to the PDP.)
...
Policies will need to refer to resource, subject and environment attributes to evaluate requests. How will the PDP resolve the referenced attributes? What is the most straightforward way to create an extensible mapping of XACML attribute to contextual repository data, given a node resource path?
Resource Attributes
Uses cases mention enforcement scenarios based on resource attributes, namely mime-type and mix-in types.
...
It might be nice if Fedora developers can define the attributes used in policies by referencing URIs they already see in the object resource graph representation.
Given a particular ModeShape property has been found, the data-type can be tested vs. the requested data-type and they should match so that literal values in a policy can be compared with returned values.
...
We build a Resource Attribute Finder Module that is configured with a map of the resource attributes supported in policies. Each attribute has an ID, a data type, an expression, and expression type/grammar. The expressions are interpreted relative to the context node resource in these grammars:
- SPARQL query (plugging in the URI of the resource by replacing a {{resource}} token in the configured query text)
- can return many results in one query, which will lead to a bag of attribute values (expected by XACML)
- can also return multiple "columns" of result data, however only one attribute id is requested by the PDP in the attribute finder method. So there seems to be no use for secondary results columns.
- RDF Predicate URI (returns the objects of any triples where context nodes resources is the subject)
- this is a sort of degenerate case of SPARQL, but supporting this would make mapping simple attributes easier.
...
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:
- 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.
- Then you find the nearest parent with a policy property.
- Then you read in and return the policy XACML. (There is a PolicyReader class you can use here)
- 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 will be 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 will resolve attribute IDs (URIs) to RDF properties on fedora objectsresources. 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 object 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 will retrieve 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 object resource in the repository. Internal policy element identifiers for the XACML elements PolicyId and RuleId will have the urn prefix
fcrepo-xacml.
...