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

Meeting Logistics:

• Time: 10:00am PDT / 1:00pm EDT

• ZOOM connection: https://notredame.zoom.us/j/94030214208
  (link will launch Zoom client – if you do not have Zoom, expand the instructions below)
  
  

Agenda

(meeting notes below)

• Topics from May 2021 Dev Congress
  
  

  • Hyrax ACL & Authorization Group Whiteboarding

Facilitators: @Lynette Rayle, @tamsin johnson, @Jeremy Friesen 

Notetaker: @Juliet Hardesty

Attendees:

• @Jeremy Friesen

• @Daniel Pierce

• @Chris Colvard (Deactivated)

• @Maria Whitaker

• @Michael Johnson

• @Jon Cameron

• you

• you

Meeting Process

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