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)
  

  Meeting ID: 940 3021 4208 One tap mobile +13017158592,,94030214208# US (Germantown) +13126266799,,94030214208# US (Chicago) Dial by your location +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 6833 US (San Jose) Meeting ID: 940 3021 4208 Find your local number: https://notredame.zoom.us/u/aPls29JbL Join by SIP 94030214208@zoomcrc.com Join by H.323 162.255.37.11 (US West) 162.255.36.11 (US East) 115.114.131.7 (India Mumbai) 115.114.115.7 (India Hyderabad) 213.19.144.110 (EMEA) 103.122.166.55 (Australia) 64.211.144.160 (Brazil) 69.174.57.160 (Canada) 207.226.132.110 (Japan) Meeting ID: 940 3021 4208

  
  

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