• FedoraXACML Evaluation Summary

FedoraXACML Evaluation Summary

First Draft

• Assumption: Authentification is done outside DOMS. We are only concerned with authorization.
• Documentation: Seems Fedora Authorization with XACML Policy provides what we need, but we have not done a full analysis of 'what we need'.

  • We can specify an object-specific policy within the object's policy datastream. This datastream can refer to a policy in a 'license object' (rights object). The XACML policy of this license object can however not include a policy from a 'parent' license object. Note that this means that we have both a 'hasLicense' relation from object A to it's license object B and a reference from the policy datastream in A to a policy datastream in B. This means that there is a risk the two references get 'out of sync'. We however need the policy reference, and we want the RELS-EXT relation, as the license object also holds a textual description...

• Test: postponed

• We have decides on a DOMS architecture with a journaling style Fedora-Front and Fedora-Back, and we would like to enforce only repository wide policies for Fedora-Front (for the in-house DOMS manager GUI)

  <param name="VALIDATE-OBJECT-POLICIES-FROM-DATASTREAM" value="false"/>

  and both object policies and repository wide policies for Fedora-Back (for the read-only oai-harvester).
• We want full edit rights for all in-house users, i.e. all users of the GUI.
• Questions:
  • Who edits XACML policies? How? When?
  • Which attributes do we need? 'Access to material with this License'-attributes? Who manages those (i.e. manages which users have which attributes)?
  • Do we want to be able to create new attributes in connection with new collections?