16815 authz design #17094
16815 authz design #17094
Conversation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Manifest Files |
|
Easy access to see how the page looks rendered |
Integration Test Results 60 files 60 suites 44m 5s ⏱️ Results for commit 6103dc2. ♻️ This comment has been updated with latest results. |
Co-authored-by: Arnej <[email protected]>
…/prime-reportstream into platform/jamie/16815-authz-design
| | org:write | Able to update organizations | ReportStream-OrgAdmin | | ||
| | org:read | Able to access read-only information related to organizations | ReportStream-User | | ||
| | submit | Able to submit reports | ReportStream-Submit | | ||
| | elims | Special `elims` specific actions (see below) | ReportStream-Elims | |
There was a problem hiding this comment.
Hmm I don't really like the idea of this, it's coupled to a particular customer's use case. Instead we should look to try to understand the use case in a "generic" way. For example, what would a generic name for this scope be? I think there wouldn't be one because its a mishmash to serve a weird edge case?
I think I would prefer we don't support this and instead force users to create new accounts if they want a particular role for a particular organization? So that means:
If a user has a "scope group" those scopes will apply to all "org groups". If we want a user to have different "scope groups" for different "org groups" that will not be supported and instead a new user account should be created. This makes sense to me because from an organizational perspective that IS a different user.
For example, if I worked for CDC and Palantir, I would have two different accounts, one for each organization, and if the two companies work closely together and communicate via slack, I could log in to slack with either of my two different accounts and have different permissions depending on what account I am signed in under.
There was a problem hiding this comment.
For example, what would a generic name for this scope be? I think there wouldn't be one because its a mishmash to serve a weird edge case?
We could break it out into something like the following if it would be more clear.
submissions
daily-data
If a user has a "scope group" those scopes will apply to all "org groups". If we want a user to have different "scope groups" for different "org groups" that will not be supported and instead a new user account should be created. This makes sense to me because from an organizational perspective that IS a different user.
I'm a little confused on this. Okta groups are serving multiple purposes in this design. The ReportStream-* groups serve as a way to show what users are able to request certain scopes. The org groups are the more standard md-phd type showing what organization your scope will apply to.
For example, if I worked for CDC and Palantir, I would have two different accounts, one for each organization, and if the two companies work closely together and communicate via slack, I could log in to slack with either of my two different accounts and have different permissions depending on what account I am signed in under.
I didn't particularly like this idea but it greatly simplifies authz setup. I also think it wouldn't be terribly common as most users are tied to a specific organization.
There was a problem hiding this comment.
Okay I think I figured out at least part of what's not sitting right with me. I think we are actually trying to combine user/group permissions (scopes) with organization settings. For example: If we want to give CDC_ELIMS organization permission to view NY's daily data page, then that's not a new scope, but a new organization setting (managed in RS settings database), like so:
NY_DPH
- allow-daily-data-access: [CDC_ELIMS]
There was a problem hiding this comment.
UPDATE/TODO: Jamie, Surya, and I met on call and discussed this in more detail. We agreed that we should look into, and document, the possibility of splitting the "elims" scope into "organization settings". Concrete todo tasks:
- Investigate how/where "organization settings" can be managed and evaluate pro/cons and document desired solution. Some possibilities we discussed were storing settings in:
- Okta itself
- RS Postgres DB
- New DB/table in Azure
- Think through what "organization settings" we would want and what use-case they would serve. For example:
allow-daily-data-access: [Organization_B]allowsOrganization_Baccess to the Daily Data page of the organization the setting belongs to. Review the mural linked in the ticket/epic to ensure we cover all documented needs.
There was a problem hiding this comment.
Update this section
| | org:write | Able to update organizations | ReportStream-OrgAdmin | | ||
| | org:read | Able to access read-only information related to organizations | ReportStream-User | | ||
| | submit | Able to submit reports | ReportStream-Submit | | ||
| | elims | Special `elims` specific actions (see below) | ReportStream-Elims | |
There was a problem hiding this comment.
UPDATE/TODO: Jamie, Surya, and I met on call and discussed this in more detail. We agreed that we should look into, and document, the possibility of splitting the "elims" scope into "organization settings". Concrete todo tasks:
- Investigate how/where "organization settings" can be managed and evaluate pro/cons and document desired solution. Some possibilities we discussed were storing settings in:
- Okta itself
- RS Postgres DB
- New DB/table in Azure
- Think through what "organization settings" we would want and what use-case they would serve. For example:
allow-daily-data-access: [Organization_B]allowsOrganization_Baccess to the Daily Data page of the organization the setting belongs to. Review the mural linked in the ticket/epic to ensure we cover all documented needs.
|
| | org:write | Able to update organizations | ReportStream-OrgAdmin | | ||
| | org:read | Able to access read-only information related to organizations | ReportStream-User | | ||
| | submit | Able to submit reports | ReportStream-Submit | | ||
| | submissions | Able to access submissions page | ReportStream-submissions | |
There was a problem hiding this comment.
No longer required since both covered by org:read
| ``` | ||
|
|
||
| At a code level: | ||
| - ensure the user contains the `daily-data` scope |
There was a problem hiding this comment.
simplify because daily-data page is only 1 receiver at a time
This PR documents a new design for authorizing endpoints in ReportStream.
Linked Issues