XACML default policies cause collections to become inaccessible

[bro...@wwu.edu]

Hi,

We are actively working on rolling out Islandora at our institution and I am running into a roadblock when trying to leverage XACML and the API.

Currently we are running Islandora 1.8.

Following the documentation at https://github.com/Islandora/islandora_xacml_editor#fedora-configuration and https://wiki.duraspace.org/display/ISLANDORA715/Using+the+Object+Policy+tab+to+manage+access+restrictions+with+XACML I believe I have it setup and configured properly. No tests fail for the XACML or XACML API modules either. I have confirmed that the drupal filter works as well.

As soon as I set any type of object policy anonymous users are locked out of the site and the following message appears in my Drupal log.

RepositoryException: Unauthorized in RepositoryConnection->parseFedoraExceptions() (line 229 of /var/www/drupal/sites/all/libraries/tuque/RepositoryConnection.php).

Anonymous users simply see a broken looking Drupal website and the following message, "Error The website encountered an unexpected error. Please try again later."

On this list serve, I found the same error, https://groups.google.com/forum/?hl=en&fromgroups#!searchin/islandora/RepositoryException$3A$20Unauthorized$20in$20RepositoryConnection-%3EparseFedoraExceptions()$20(line$20229$20of$20$2Fvar$2Fwww$2Fdrupal$2Fsites$2Fall$2Flibraries$2Ftuque$2FRepositoryConnection.php)%7Csort:date/islandora/yMTPyLQW9W4/lMdw4r9gGgAJ, except in my case, anonymous access to any item does not work as soon as I set a policy on anything.

Removing an object viewing policy does not fix the issue either. However, disabling the modules fixes it instantly.

What would be the next logical debugging steps?

Thank you,

Max

[Brandon Weigel]

Did you make sure to allow the Fedora user and the Admin user at minimum?

[Jared Whiklo]

Max,

That horribly useless error in the Drupal log will correspond to a much
more useful error in your tomcat log, because Fedora has a problem.

Can you check your tomcat logs and see what is happening?

cheers,
jared

On 2017-11-22 3:29 PM, Brandon Weigel wrote:
> Did you make sure to allow the Fedora user and the Admin user at minimum?
>
> On Wednesday, 22 November 2017 16:25:13 UTC-5, bro...@wwu.edu wrote:
>
> Hi,
>
> We are actively working on rolling out Islandora at our institution
> and I am running into a roadblock when trying to leverage XACML and
> the API.
>
> Currently we are running Islandora 1.8.
>
> Following the documentation at
> https://github.com/Islandora/islandora_xacml_editor#fedora-configuration
> <https://github.com/Islandora/islandora_xacml_editor#fedora-configuration>
> and
> https://wiki.duraspace.org/display/ISLANDORA715/Using+the+Object+Policy+tab+to+manage+access+restrictions+with+XACML
> <https://wiki.duraspace.org/display/ISLANDORA715/Using+the+Object+Policy+tab+to+manage+access+restrictions+with+XACML>
> I believe I have it setup and configured properly. No tests fail for
> the XACML or XACML API modules either. I have confirmed that the
> drupal filter works as well.
>
> As soon as I set any type of object policy anonymous users are
> locked out of the site and the following message appears in my
> Drupal log.
>

> /RepositoryException/: Unauthorized in
> /RepositoryConnection->parseFedoraExceptions()/ (line /229/ of
> //var/www/drupal/sites/all/libraries/tuque/RepositoryConnection.php/).

>
> Anonymous users simply see a broken looking Drupal website and the
> following message, "Error The website encountered an unexpected
> error. Please try again later."
>
> On this list serve, I found the same error,
> https://groups.google.com/forum/?hl=en&fromgroups#!searchin/islandora/RepositoryException$3A$20Unauthorized$20in$20RepositoryConnection-%3EparseFedoraExceptions()$20(line$20229$20of$20$2Fvar$2Fwww$2Fdrupal$2Fsites$2Fall$2Flibraries$2Ftuque$2FRepositoryConnection.php)%7Csort:date/islandora/yMTPyLQW9W4/lMdw4r9gGgAJ

> <https://groups.google.com/forum/?hl=en&fromgroups#!searchin/islandora/RepositoryException$3A$20Unauthorized$20in$20RepositoryConnection-%3EparseFedoraExceptions()$20(line$20229$20of$20$2Fvar$2Fwww$2Fdrupal$2Fsites$2Fall$2Flibraries$2Ftuque$2FRepositoryConnection.php)%7Csort:date/islandora/yMTPyLQW9W4/lMdw4r9gGgAJ>,

> except in my case, anonymous access to any item does not work as
> soon as I set a policy on anything.
>
> Removing an object viewing policy does not fix the issue either.
> However, disabling the modules fixes it instantly.
>
> What would be the next logical debugging steps?
>
> Thank you,
>
> Max
>
>

> --
> For more information about using this group, please read our Listserv
> Guidelines: http://islandora.ca/content/welcome-islandora-listserv
> ---
> You received this message because you are subscribed to the Google
> Groups "islandora" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to islandora+...@googlegroups.com
> <mailto:islandora+...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/islandora.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/islandora/bffaa213-d6ea-413e-8928-89c54b5fea1f%40googlegroups.com
> <https://groups.google.com/d/msgid/islandora/bffaa213-d6ea-413e-8928-89c54b5fea1f%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
Jared Whiklo
jwh...@gmail.com
--------------------------------------------------
Some people have a way with words, others not have way.

[dp...@metro.org]

Hi Max,


Could you share with us your Fedora default XACML policies (tree -a on /usr/local/fedora/data/fedora-xacml-policies/repository-policies/default) and/or (/usr/local/fedora/data/fedora-xacml-policies/repository-policies/islandora)

My guess is: If tuque is failing there, means the invalidation(Authz level) seems to be happening on Fedora itself and the most commons scenario is the presence (means, you need to remove that) of deny-policy-management-if-not-administrator.xml, which actually blocks anonymous users to be even able to read policy datastream, means enforcing (even permissive XACML) is impossible for anonymous, basically blocking any type of XACML for that role.

Your islandora is 2 versions behind. If all your policies are OK (and you are actually sure Fedora is reading them fresh from files, means you reloaded them or restarted fedora) then I would suggest increasing the fedora authz logging level to "fine". or whatever equivalent your logging library has additionally to Jared's suggestion on the main catalina log and/or fedora server log.

Let us know how that goes

Diego Pino

Metro.org

[bro...@wwu.edu]

Oi!

Thank you all for your suggestions. I had deleted the deny-policy-management-if-not-administrator.xml file but had not restarted Tomcat. Doing that was the final step. XACML now works as I imagined it would. I wish I could edit the doc page to add that important final step. https://wiki.duraspace.org/display/ISLANDORA/XACML+Editor

Thanks again,

Max