...
- 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
...
- 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