This is an implementation of the authorization delegate API. This PEP compiles request and environment information into an authorization request that is passed to a XACML policy decision point (PDP).

Requirements

• 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 (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

Decisions Needed

How to Map to XACML Policies

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.

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 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. 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.)

How to Map XACML Attributes to Repository Data

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 path?

When a property is not set, then the attribute finder needs to return an empty-set. (This is true for all attribute finding.)

Resource Attributes

Uses cases mention enforcement scenarios based on resource attributes, namely mime-type and mix-in types.

Ways we might map a resource attribute to a property value (preference for those friendly to Fedora developers):

• 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 query
• XPath-like JCR expression

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:

• JCR 1.0 XPath
• RDF Predicate URI (returns the objects of any triples where context nodes is the subject)

Issues

Do we need SPARQL? How do we inject the context node path or URI? (help)

Subject Attributes

Policies will want to reference attributes of the subject.

One idea is to map as much as we can through the servlet request and it's headers, i.e. a pass-through of request headers related to subjects.

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 an ID, a data type, an expression and expression type/grammar:

• group, string, header: X-forward-group-name, request-context
• IP, string, IP, request-context
• role, string, role, fedora-context (maps to the effective fedora roles for a node)

Issues

There has to be a cleaner way to express these mappings, right? A dotted expression language? (help)

Shall we use the JBoss PicketBox XACML Engine?

PicketLink and PicketBox projects use the same XACML PDP, which is the Sun XACML implementation repackaged by JBoss. (PicketLink is a larger umbrella project of security services.)

The JBoss XACML engine has no significant runtime dependencies, outside of a PicketLink utilities jar. The other dependencies are the Java Servlet API and XML APIs.

APIs to look at:

• org.jboss.security.xacml.sunxacml.finder.PolicyFinderModule is used to find a policy (or policy set) that matches the request evaluation context. Also used to lookup a policy that is referenced within a policy set by ID.
• org.jboss.security.xacml.sunxacml.finder.AttributeFinderModule is used to find attribute values when evaluating a policy.
• Constructing a policy set for the JBOSS engine:
  • see JCR 2.0 16.3 and JBossLDAPPolicyLocator as an example.

Propose Yes

The Sun XACML engine has been around for a while and seen plenty of production use. The JBoss project is also relied upon by a larger security framework.

Issues

It seems configurable enough, but that would be the main reservation and is to be determined.

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.

Proposed

Local. This presents fewer obstacles in the short term and we have no use cases yet which dictate that a remote XACML PDP is needed. A local PDP makes this authz delegate easier to configure since no fedora, modeshape or SOAP XACML clients need to be set up between the separately running services. If we ever need the PDP to be remote we can do the extra plumbing to make it so.