1. Cleanup of APIs, possibly drop APIA/APIM distinction
      1. For example, listing available DS is an APIM call but view them is an APIA. This leads to additional challenges in coding that are
      2. Combine the APIs or make a better distinction, so Manage and Access is a reasonable distinction, but needs to be rethought
    2. Tighter Integration of Security via FESL or an undefined security mechanism
      1. Queries only reporting objects you can see
      2. API operations returning things you have access to

4 Comments

  1. David Wilcox

    Ready for testing as of 4.0-Alpha-4.

  2. Nigel Banks

    Point a. is definitely handled the API is much cleaner.
    I'm not sure to what extend Point b. has been met.
    Solr and the Triple store are external to Fedora, so they won't be supporting hiding objects / datastreams based on the user that made the query? Is their any ideas / preliminary work on this front? 
     
    Admin Search, Does support b.i according to here.
    Point b.ii seems to be met with RESTful HTTP API#AccessRoles, but I'm curious if we could also get per user access returned as well? Also what about management rights? Could there be a simple interface for that? It looks like the Access Roles Module adds the <path to object>/fcr:accessroles rest end point. So I imagine we could build extensions to provide additional info via more rest end-points?

    1. Andrew Woods

      Thanks for the feedback, Nigel Banks.

      Solr and the Triple store are external to Fedora, so they won't be supporting hiding objects / datastreams based on the user that made the query? Is their any ideas / preliminary work on this front? 

      Access controls over external services have not been designed out. However, a json (at the moment) representation of each object/datastream ACL is available by requesting

      GET <path-to-resource>/fcr:accessroles

      It would certainly be possible to index this information in the external services to facilitate authz on that side.

       

      but I'm curious if we could also get per user access returned as well?

      What do you mean by the above exactly?

       

      Also what about management rights?

      Are you suggesting a new role, "access-manager", that could be granted to users who are able to update ACLs?

  3. Nigel Banks

    I was referring to the same REST end-point you referenced. From the name of it and the description I found in the documentation on the REST-API page, I assumed it would list roles that have read access rights to that object. I was wrong though how I interpreted it, after reading through Access Roles Module I realized my mistake. I think the use cases on this page are covered by the Alpha-4 release.

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