Page History

This is a Fedora Policy Enforcement Point (PEP) implementationan 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 (proposed):

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

Design Notes:

•  Constructing a policy set for the JBOSS engine:
• This policy enforcement point is aware of access roles. The effective roles for the current request will be added to every XACML permission check. Policies may pivot on access roles.
• Policies and PolicySets are stored inside Fedora (in a dedicated ModeShape workspace)
• Administrators may create separate realms of XACML policy at any point within a repository tree. For instance a collection of scientific data may have different roles or access rules than a collection of PDFs.
• Any object in the Fedora repository tree may be linked to a PolicySet, which then defines the effective policies for the subtree until another link overrides the PolicySet.
  
  • see JCR 2.0 16.3 and JBossLDAPPolicyLocator as an example.
• Need to map XACML attributes to the repository, given a context node.
  • JCR query or XPath?
  • How to determine XACML data type?
  • Can we write a extensible
  ?? Standard and customized XACML attribute mappings could be stored in the repository. (JCR query, data type, attribute ID)
  
  • Write an "attribute finder" based on relative JCR XPath.
• ModeShape Question: How best to store policies within the repository? (normal nodes/properties or possibly behind the AccessManager API)

Option: Internal PDP vs. External

• • ?
• Should we implement a local or remote PDP?
• Should we use JBoss XACML Engine?
• Use JCR API for attribute lookups
  
  • Always store as much as possible in the repo itself. (A. Soroka)
• Less penalty for light authZ requests (i.e. use more attribute lookups based on Fedora object model)

Components

...