Samvera Topical Tech Call 2021-05-26 - Hyrax ACL & Authorization

Owned by Juliet Hardesty
Last updated: May 28, 2021

Meeting Logistics:

Agenda

(meeting notes below)


Facilitators: Lynette Rayle, tamsin johnson, Jeremy Friesen 

Notetaker: Juliet Hardesty

Attendees:

Meeting Process

 Facilitators and Note Taker - click to see meeting process...
  1. Topical Tech Call has focused agenda - following steps adjusted
  2. Standing pre-agenda items (facilitators)

    1. Welcome

      • "Welcome everyone, please add your name to the Attendees list.  If you are unable to do so, please let us know, and someone will add you. To any newcomers, Welcome, and please feel free to ask questions. Likewise for all attendees. We strive for an open and accessible conversation around Samvera technology."

    2. This is extra scheduled Tech Call for topics brought up at Dev Congress that require discussion
  3. Follow Agenda from above (facilitated by moderator) and record notes in Notes section below (note taker)
  4. Reminder for next Topical Tech Call (Thursday, May 27 10am Pacific/1pm Eastern)


Notes

  • select one topic for today - ACL & Authorization Group
  • Nested Indexing will be tomorrow
  • Github issue: Work is not visible to owner in a mediated workflow if embargo selected - https://github.com/samvera/hyrax/issues/3817
    • more discussed in issue regarding permissions than just this described issue
    • short-circuiting ability class
    • controller logic doesn't necessarily make sense for why you would arrive at the situation described in the issue
    • sipity workflow lands you in this spot, it looks like
    • implementation rule suggestion: way we determine object level access is through ACL only
      • object has ACL with permissions assigned (a mode and an agent/user/group)
      • ACL handles read, discover, edit over users and groups
      • always positive access grant (does not say who cannot have access)
    • this issue describes circumstance where particular user (depositor) does have read access even though there is no ACL that grants that access - that should be wrong if we go with ACL-defined access
    • one caveat: Fedora has object status (pretty sure just inactive or active but there might be other statuses as well) - Hyrax only uses inactive and that is what underlies "suppress"
      • ACL and suppress flags are re-implemented in Valkyrie adapters, by the way
  • how is strictly following ACL problematic?
    • IU and Avalon permissions are not necessarily just object level permissions so there are other things to consider
    • object level permissions should maybe refer to repository object permissions (PCDM-level considerations, so file or fileset or collection or repository object)
  • sipity workflow and its understanding of permissions
    • state machine that sipity knows is state of workflow (so not Fedora active/inactive object state)
    • knows who can take an action for a given workflow state
    • when state changes, sipity should be able to modify ACLs
      • there's some dangers there since ACLs on object can be modified outside of sipity and that could conflict with sipity modifying ACLs
  • for things that have ACLs, the ACL is the law
  • workflow authorization (sipity engine determines if user is in role that can do an action/state transition)
  • cancan authorization (mostly, what a user can do from controllers - is user authorized to view page/download object)
  • these 2 authorizations are floating above ACLs and should respect ACLs
  • getting sipity to follow rules that way can cause the conflict described earlier when state changes
  • use cases: https://docs.google.com/spreadsheets/d/1WWrMgcVo9nF_EdyFuD6npNg4_CV4nMU55DMTCP0-rkk/edit#gid=0
    • user role and state make difference for permissions
    • Avalon doesn't use self-deposit
    • group level permissions based on state in deposit cycle (published or not published in Avalon, for example)
      • group can read item if item is published - example
  • sipity functions can change ACLs but this can make implementing these example use cases challenging
  • on tech side, stick with ACL model or not; if not, different conceptual model needed for granting ACLs
  • having exceptions to ACLs is suspected to be causing buggy behavior (from issue above)
  • use case examples can be represented in database so it might not be difficult to represent them for look-up
  • Hyrax codebase is not implementing this via database; code layered on top of ACLs with complicated logic checks that are hard to decipher
  • use cases are showing authorization and need strategy for authorization that works with data layer access rules
  • Fedora object has ACL so that if Fedora goes away, we have ACL XML that defines access and can still be used
  • normalizing checks into cancan might help straighten things outs with the logic being applied now and what needs to be applied for defined use cases
  • Hyku has some role-based logic applied - maybe Chris Colvard (Deactivated) can provide info?
  • need to re-term problem as authorization, then name actions to authorize
  • spreadsheet from LaRita Robinson has that info
  • now might be time to squash out if editor? checks and move them in to cancan; next refactor it is easier to implement can grant proxy
  • cancan is current interface layer and if everything is moved to that we have pivot point in code to make these changes
  • permissions and authorizations - what is difference?
    • permissions is broad and captures at least 2 different models of access (access control rules - ACLs, endpoint authorization); different in codebase
    • repository model issue and not just technical issue
    • authorization at code layer that is missing unified strategy so far, below that is ACLs that do have well-defined model
    • permissions is those 2 things together and difficult to articulate outcomes that can be reconciled with the way things are set up
    • ACLs are authorization and layer that executes those is something else?
      • authorization is wanting to perform action as user/role/group - am I authorized to do action?
      • ACLs more narrow and specific - govern access to data (objects in backend)
    • ACL authorizes specific set of actions on database
    • ACL is like database entries and authorization layer is on top of database entries
    • code layer and database layer
      • cases where database layer (ACL) says one thing and code layer (logic checks) is doing another
  • Agreement: database layer (ACL) should be where rules are declared and code layer (logic checks) should only implement those rules, not make new ones
  • Path forward
    • with this issue, workflow is not working in terms of the access model, doesn't throw a cancan and knowingly cheats the model
    • we need to move any of the if document.state? or if persons/roles/groups checks out of the controllers and views and into cancan to refactor
    • make it clear this refactor is happening, PRs might need to pre-populate with a checklist for review to include that these if checks shouldn't be there so they don't leak back in to the code
    • have deprecation strategy since implementors are likely doing these types of code checks upstream
    • commitment to create named resources that we can run cancan against - mandatory restraint
    • also need to call out places where controller view or business logic code checks for visibility
      • visibility implementations are all explicitly in terms of ACLs (public, institution, private settings)
      • need to use cancan for visibility checks unless all we are doing is displaying info
    • give cancan total ownership of authorization question, starting with this issue
    • Juliet Hardesty, Jeremy Friesen, and tamsin johnson work on getting info about ACLs and authorization relationships into Hyrax management level documentation
      • maybe use use cases from google doc as examples
      • also likely use cases from refactoring