Versions Compared

Old Version 23

changes.mady.by.user Juliet Hardesty

Saved on

compared with

New Version 24

changes.mady.by.user Juliet Hardesty

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Agenda

(meeting notes below)


Facilitators: Lynette Rayle, tamsin johnson, Jeremy Friesen 

...

  • 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 be therearrive 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 creates 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 other people could modify ACLs on object that would 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; layering 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 (not access), then name actions to authorize
  • spreadsheet from Larita has LaRita Robinson has that info
  • now might be time now to squash out if editor checks ? checks and move them in to cancan; next factor refactor it is easier to implement 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 on 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 out of the controllers and views, any of the if document.state? or if persons role/group checks into /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  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 things 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
    • JulieJuliet Hardesty, Jeremy Friesen, and tamsin johnson work on getting info about ACLs and authorization relationship relationships into Hyrax management level documentation
      • maybe use use cases from google doc as examples
      • also likely use cases from refactorrefactoring