Date: Thu, 28 Mar 2024 14:07:21 -0400 (EDT) Message-ID: <896927050.28532.1711649241838@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_28531_366120075.1711649241837" ------=_Part_28531_366120075.1711649241837 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Islandora XACML Editor provides a graphical user interface to edit X= ACML policies for objects in a repository or collection. It adds a new tab = to each collection called Child Policy and a tab to each i= tem called Item Policy, where permissions can be set on a = per User or per Role basis for:
Object Management: Controls who can set XACML poli= cies for an object/collection.
D= rupal.org modules:
Install as usual, see this= a> for further information.
It may be desirable--and in fact necessary for some modules--to disable/= remove ene of the default XACML policies which denies any interactions with= the POLICY datastream to users without the "administrator" role.
This policy is located here: $FEDORA_HOME/data/fedora-xacml-polici=
es/repository-policies/default/deny-policy-management-if-not-administrator.=
xml
In order to comply with XACML restrictions placed on objects, a hook is =
used to filter results that do not conform to a searching user's roles and =
name. This hook will not function correctly if the Solr fields for Vi=
ewableByUser
and ViewableByRole
are not defined correct=
ly as they are set in the XSLT. These values can be set through the admin p=
age for the module.
The XACML editor hooks into ingesting through the interface. When a chil= d is added through the interface, the parent's POLICY will be applied if on= e exists.
If XACML policies are written or edited by hand, it may result in unexpe= cted behaviour.
Having problems or solved a problem? Check out the Islandora google grou= ps for a solution.