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.

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.

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.

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.

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.