...
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)Expand title Click to view telephone/H.323/SIP connection instructions 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
...
- Jeremy Friesen
- Daniel Pierce
- Chris Colvard (Deactivated)
- Maria Whitaker
- Michael Johnson
- Jon Cameron
- you
- you
...
Meeting Process
Expand | ||
---|---|---|
| ||
|
...
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 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 implementcan 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 any of the
if document.state?
orif 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