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
- 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 there
- 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 (mode and agent/user/group)
- ACL handles read, discover, edit over users and groups
- always positive access grant
- this issue creates 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 (inactive or active) - Hyrax only uses inactive and that 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 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 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
- 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 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 that info
- time now to squash out if editor checks and move them in to cancan; next factor 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