Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* dwilcox leaves05:03
* dwilcox joins06:02
* dwilcox leaves07:15
* dwilcox joins07:49
* dwilcox leaves08:32
* dwilcox joins08:39
* dwilcox leaves08:55
* ksclarke joins09:12
* scossu joins09:43
Is someone around to give me some hints on how to implement and test XACML policies?10:00
<gregjansen>scossu: I am around10:03
<scossu>Thanks Greg. What I have done so far:10:04
Set my repo.xml
<bean name="containerRolesProvider" class="org.fcrepo.auth.common.ContainerRolesPrincipalProvider">
<property name="roleNames">
<util:set set-class="java.util.HashSet">
* scossu leaves
* scossu joins10:05
<gregjansen>I presume you have access to the example role-based policies. The best thing to do is start there. When you want to change the effective policy, you just link your object/tree to your new policy set.
<scossu>I ingested the contents of https://github.com/fcrepo4/fcrepo-module-auth-xacml/blob/master/src/main/resources/policies/ReadNormalNodePermissionPolicySet.xml into /system/policies/ReadNormalNodePermissionPolicySet10:06
under fcr:content
<scossu>I have a container node under /resources/SI10:07
How do I apply these policies? I still get denied when I log in as a normal user for reading.
<gregjansen>let me see..
okay so that policy will permit anyone to read..10:08
you apply the policy by setting a property on the container node that references the policyset.. I have to lookup that property name
<scossu>Oh I also set authz:policy to http://localhost:8180/fcrepo/rest/system/policies/ReadNormalNodePermissionPolicySet
<gregjansen>the existing root node should have this property set on it, pointing to default policies10:09
<scossu>in /resources/SI
<gregjansen>I wonder if that ends up being a node reference, I would assume so
<scossu>oh I see, I have to reference the policy in the root node.
It looks like I get denied because the user has no read access to the policies node.10:10
<gregjansen>you should be able to reference the policy at any node, making it effective there and in the tree under that node
<scossu>So basically any policy can be applied to any node and it propagates to its descendants, right?
<gregjansen>to establish the policy link you would need to be a user with write perms, etc.. perhaps fedoraAdmin role
<scossu>So if I want a repo-wide policy I just reference it in the root node. That makes sense.10:11
<gregjansen>so, the authz:policy property on the root node is just a good example
<scossu>Ok, I'll test and let you know how it goes! Thanks.
<gregjansen>you bet.. have you set up the right authz delegate in repo.xml, etc??10:12
<scossu>Yes, the XACML module seems to be working.
<bean name="XACMLFad" class="org.fcrepo.auth.xacml.XACMLAuthorizationDelegate"/>10:13
<bean class="org.fcrepo.auth.xacml.PDPFactory"/>
<bean class="org.fcrepo.auth.xacml.FedoraPolicyFinderModule"/>
<bean class="org.fcrepo.auth.xacml.FedoraResourceFinderModule"/>
<bean class="org.fcrepo.auth.xacml.TripleAttributeFinderModule"/>
<bean class="org.fcrepo.auth.xacml.SparqlResourceAttributeFinderModule"/>
<bean name="authenticationProvider" class="org.fcrepo.auth.common.ServletContainerAuthenticationProvider">
<property name="fad" ref="XACMLFad"/>
<property name="principalProviders" ref="principalProviderSet"/>
<gregjansen>looks good10:15
<scossu>Ok, I moved the reference to the XACML policy to the root node10:18
tried curl -u user:password http://localhost:8180/fcrepo/rest/resources/SI
Got this: http://pastebin.com/VcTBtrEK
(user is in the Tomcat aic-imaging group)10:19
<gregjansen>aha, so the new value was added as a second property, it did not replace the first one10:30
so I guess you have to delete the existing policy property
(I guess this is a function of using SPARQL update to set the property?) I wonder if there is a way to make that property single-valued.. It should be10:31
that is, it looks like the policy set was not retrieved due to there being two policy properties set10:32
<scossu>For the existing policy you mean the rbacl role?
<gregjansen>on the root
<gregjansen>I think the root now has two policy properties, you can verify that in the graph probably
<scossu>Let me check, I didn't see it in the HTML UI10:33
<gregjansen>If you are doing a formal evaluation, I think this comes under the heading of "things that should not happen" and it would be valuable to include in your report
<scossu>I can't see any other policy in the root node.10:34
Actually I removed the ref from the root node and added it to both /system/policies and /reseources/SI
And now I can read /resources/SI as a normal user.10:35
<scossu>But I have to test further to make sure that it's not because of the basic rbacl ruls.
<gregjansen>having the policies folder point to a policy within it is probably just fine.. you will eventually need a fedoraAdmin to bootstrap new policies of course
it might be, your user seems to be in the reader role, as per the log10:36
the recent log can tell you I think, i.e. should say which policy was consuleed
This is when accessing /resources/SI/test with the basic rbacl removed from /resources/SI
so it seems to be working fine10:40
It's just in order to parse policies, I have to keep that reference to the reader policy in /system/policies, right?
<gregjansen>you should not have to.. the policy retrieval is done with a separate internal admin account10:47
<scossu>That is what I thought too.10:48
<gregjansen>can you try it without the extra ref?
(note that there is no authz request in the log for /system/policies/anything)10:49
<scossu>Ha! This is funny. I just remove the ref in /system/policies and I can still access /resources/SI/test but when I access /resources/SI (where the ref to the policy is made) I get an error.10:50
<gregjansen>looks like some code is "coming through the front door", i.e. policy finder is making an HTTP request for the policy. this looks like a bug to me10:58
strange that it doesn't happen at /resources/IS/test
<scossu>In fact I can confirm that moving the ref up to /resources I can access /resources/SI.11:02
I have a row of meetings through this afternoon, but I can keep testing when I'm back.11:03
Thanks for looking into this.
<gregjansen>np, glad you found something (in a way)11:04
* scossu leaves11:08
* scossu joins11:54
* scossu leaves12:02
* padraic71a joins12:34
* dwilcox joins12:40
* padraic71a leaves12:42
* padraic71a joins12:47
* padraic71a leaves12:53
* edInCo joins13:13
* dwilcox leaves13:45
* dwilcox joins13:48
* edInCo leaves14:28
* gregjansen leaves14:52
* scossu joins15:53
* fcrepo-bot joins15:58
* padraic71a joins16:04
* padraic71a leaves16:12
<pivotal-bot>Stefano Cossu added "XACML policy is valid for descendants of node it is applied to, but throws error on actual node" https://www.pivotaltracker.com/story/show/7323298616:31
Stefano Cossu edited "XACML policy is valid for descendants of node it is applied to, but throws error on actual node" https://www.pivotaltracker.com/story/show/7323298616:32
* fcrepo-bot leaves17:42
* dwilcox leaves18:01
* ksclarke leaves18:17
* scossu leaves18:31
* scossu joins23:28

Generated by Sualtam