1. The features of the phase 1 implementation as described would seem to suit our use cases very well.  I think we will be able to carry out most of our initial implementation plan using these features.
  2. The highest priority for us in phase 2 would be to add agent classes.  This would seem to enable much easier management of access as the roles of individual users within our organization change over time.
  3. In practice, beyond creating ACLs, authorizations, and connecting resources to them, I have not been able to test very effectively whether or not the system in fact behaves as expected, which is why I said "as described" in #1 above.
  4. Using the existing Vagrant, I was able to authenticate at "fedoraAdmin" in my browser, and create various resources, ACLs, and authorizations, but I could not test very effectively because my browser seemed to want to return a 403 forbidden error whenever I attempted to access anything as any user other than fedoraAdmin.  I'm not sure if that is because the "testuser" and "adminuser" I used in my authorizations was not recognized as the same user as when I logged in using the supplied test accounts, or whether I was doing something wrong.  I tried clearing the browser cache, restarting the browser, and using a different browser.  In every case, the only user who could access any resources in my testing instance was fedoraAdmin.  All other users received 403 forbidden.  Perhaps the root of the repository needs an ACL which allows full read access to all users?
  5. I would be happy to test more if someone would be able to provide some guidance how to do so with the existing set of user accounts.  It would be nice to be able to put the implementation through its paces and see if all the behaviors are as advertised, but I have not been able to do so thusfar.  Perhaps a fuller testing capability can be one of the goals of the phase 2 sprint.
  6. Unfortunately, I will not be at the meeting today, due to a conflict.
  • No labels

5 Comments

  1. Andrew Woods

    Thanks, Joshua Westgard. Can you describe in exact detail one of the scenarios you have unsuccessfully tried to test as it relates to item #4.

    For example,

    • what exact resources did you create
    • what exact ACLs did you create
    • what exact authorizations did you create

  2. Joshua Westgard

    In the interest of facilitating today's meeting, a very quick answer now. I can provide more details later.  I created the following resources:

    • rest/acl1
    • rest/acl1/authorization1
    • rest/acl1/authorization2
    • rest/acl2
    • rest/acl2/authorization1
    • rest/acl2/authorization2
    • rest/collection1
    • rest/collection1/item1
    • rest/collection1/item2
    • rest/collection1/subcollection
    • rest/collection1/subcollection/item3

    Acl1 has two authorizations, one which allowed read/write access to adminuser, the second allowed read access to testuser.

    Acl2 likewise has two authorizations, one allowing read access to adminuser, and the other allowing read/write access to adminuser (the idea being to test the "more permissive" rule.

    Collection1 points to acl 1.

    Subcollection points to acl 2.

    I think this setup would allow one to test most of the features of phase 1.

    1. Andrew Woods

      Thanks for detailing the structure. Can you also provide either the SPARQL-Update requests you made or the resultant properties/triples on:

      • acl1/authorization1
      • acl1/authorization2
      • acl2/authorization1
      • acl2/authorization2
      • collection1
      • collection1/subcollection

       

  3. Joshua Westgard

    Thanks, Andrew.  Today I decided to take a step back and try again with the simplest possible examples.  I think I figured out where I had gone wrong.  I had defined my authorizations following the examples in the slides from the DCFUG meeting, without realizing that I was declaring authorizations to a class without first having declared my objects to be members of that class:

    <> a acl:Authorization ;
acl:accessToClass pcdm:Object ;
acl:mode acl:Read, acl:Write ;
acl:agent "adminuser" .

    Once I added the type pcdm:Object to the object that the parent ACL was pointing to, I could then access it with adminuser.  What I had meant to declare in my authorizations was the property acl:accessTo.  Now that I have a better understanding of what to expect in terms of the user accounts and responses, I can give my test scenarios another go.  I will document what I do and what I find and post it here.

     

    1. Andrew Woods

      That is great to hear, Joshua Westgard. Thanks for the update.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.