...
- 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 may reference any value obtained via a SPARQL query, relative to the content node, 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 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
...
This includes how policies are stored in the repository and how they are linked with content objects.
Proposed
Policy Persistence
Policy and Policy Set nodes 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 that contain XACML XML.
Policy sets will contain Fedora URI 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. Policy sets can define a tree structure of policies.
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 node, pointing to the policy nodes mentioned in the folder.XACML. This will prevent any policies still referenced from being deleted.
Finding the Effective Policy Set
One policy set in this the workspace will be configured (in the XACML Policy Finder Module) as the default policy , which for the workspace. This is the same as saying that this default 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.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 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 Locator will implement XACML Policy Finder Module and the Policy Locator interface. It will retrieve the policy or set that is in scope effective 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 from policy sets at the request of the PDP, looking in the policy folder to find policies that are referenced in other policiesworkspace by policy URI.
Note: When combining XACML policies in sets, you specify a combining algorithm of either permit-override or deny-override. For this reason the policy property is single-valued.
Here is an example repository tree:
- ROOT
- collection A
- policy property (REFERENCE to --> policy A)
- collection B (inherits default policy set from ROOT)
- policies
- default policy set (XACML policy set contains links to B and C)
- policy set A (nt:file, referenceable) (XACML policy set XML XACML contains links to default and D)
- policy B
- policy C
- policy D
- Â collection X
- policy set Z(XACML contains links to Y and W)
- policy Y
- policy W
- My Documents
- policy property --> policy set Z
- collection A
No Applicable Policies
This situation can arise when the only policy set (or policy) for some content contains a target element or any other XACML construct that restricts it's applicability to authz requests. If the PDP can find no policy that targets the request, it returns a NOT_APPLICABLE result to the XACML AuthZ Delegate. The delegate will then return false to modeshape, indicating that the action is not permittedWhen combining XACML policies into sets, you have to also specify a combining algorithm of either permit-override or deny-override. For this reason we always 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?
...
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. Such policy set nodes 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.)
Attempting to address all of these issues through the Sequencer approach to policy references, see above. This would map the XACML policy tree into the repository without sacrificing any of the expressiveness of XACML or creating a more robust translation.
How to Map XACML Attributes to Repository Data
...
- Predicate URI (in the RDF sense)
- Property name (effectively same as above, but more tied to modeshape API)
- Mix-in Type (another case of a predicate)
- SPARQL query
- JCR queryXPath-like JCR expression
- JCR 1.0 XPath
It might be nice if Fedora developers can define the attributes used in policies by referencing URIs they already see in the object 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.
Proposed
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 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 is the subject)
- this is a sort of degenerate case of SPARQL, but supporting this would make mapping simple attributes easier.
Issues
Do we need SPARQL? How do we inject the context node path or URI? (help)RESOLVED: Yes, we prefer SPARQL over JCR 1.0 XPaths.
Subject Attributes
Policies will want to reference attributes of the subject.
...
We can add the effective access roles to the XACML request, and/or make them available via the attribute finder module.
Proposed
We build a Subject Attribute Finder Module that is configured with a map of the subject attributes supported in policies. Each attribute has set of standard subject attributes and some ways to map any additions.
Standard subject attributes:
- fedora access roles (e.g. reader, writer, foo. these are arbitrary strings assigned to principals)
- tomcat role (fedoraAdmin, fedoraUser, etc..)
- TBD
Each additional attribute must be specified with an ID, a data type, and an expression and expression type/grammar:as follows:
- <ID>, <type>, <source>, <key>, [separator]
- group, string, request-header: , X-forward-group-namegroups
- enrollment-status, string, request-contextattribute, studentStatus
- favorite-colorIP, string, IP, request-contextrole, string, role, fedora-context (maps to the effective fedora roles for a node)attribute, favColor
Issues
There has to be a cleaner way to express these mappings, right? A dotted expression language? (help) Resolving this by creating a number of standard subject attributes, while leaving the door open for mapping new ones from HTTP headers or request attributes.
Shall we use the JBoss PicketBox XACML Engine?
...
It seems configurable enough, but that would be the main reservation and is to be determined.
We still need to implement the interfaces and JBoss documentation is an issue. However, JBoss source includes several examples of attribute/policy locators, which are our main extension points.
Local or Remote PDP?
Is this better implemented as a remote or a local PDP service. The PDP can be used as a bean without the webapp runtime, or it can be configured as a separate service (SOAP). The trade-offs are identified in the table below.
...