This Confluence wiki site, maintained by DuraSpace prior to the recent merger with LYRASIS, will transition from the duraspace.org domain to the lyrasis.org domain on Saturday, Nov 16 beginning at approximately 7pm ET. A period of downtime of 2-3 hours is expected. After the transition, this wiki will be available at https://wiki.lyrasis.org/. All links to duraspace.org wiki pages will be redirected to the correct lyrasis.org URL. If you have questions prior to or following the transition please contact: wikihelp@lyrasis.org.
Page tree
Skip to end of metadata
Go to start of metadata
    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. 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. 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?

  2. 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.