Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read access considerations - Managing sources access and correcting permission templates #2398

Open
rkboyce opened this issue Sep 17, 2024 · 1 comment

Comments

@rkboyce
Copy link
Contributor

rkboyce commented Sep 17, 2024

Expected behavior

For Atlas/WebAPI deployments using the 'read restricted configuration' (see description in the Atlas set up guide and more details on the WebAPI wiki, users with the 'Read restricted Atlas users' role should be able to use the Atlas Search feature and other functionality that requires access to a given source

Actual behavior

With the 2.14 release, the default source access was dependent on a specific string ('basic_cdm'). However, organizations can name their sources anything. So, most deployments would find that their users could not access the Search feature out of the box.

Steps to reproduce behavior

Deploy 2.14 fresh following the instructions in the wiki referenced above but have the source(s) named differently.

Discussion / actions needed

An attempt to fix this issue was implemented and pull request created (#2342). However, the pull request actually tried to address two issues: 1) adding read permissions for the 'atlas read restricted' role to existing sources, and 2) addressing some missing permissions in the WebAPI permissions templates needed for read permissions to work properly. Moreover, the consensus is that having a flyway script to add source READ permissions is not a good idea b.c it will give a false sense of security to users that the user will have read access any new sources added after the WebAPI update. At today's call (09/17), the idea was proposed to move any management of source 'read' access to the options provided in the Admin section of Atlas.

This issue is meant to:

  1. call out the parts of pull request that should be retained (after testing) because they add desired permissions to the permission template. Based on the pull request, the following seem relevant and need to be test:
  • src/main/java/org/ohdsi/webapi/security/model/CohortDefinitionPermissionSchema.java: ("cohortdefinition:%s:version:get", "Get list of cohort versions"), ("cohortdefinition:%s:version:*:get", "Get cohort version"), ("cohortdefinition:%s:copy:get", "Copy the specified cohort definition")
  • src/main/java/org/ohdsi/webapi/security/model/ConceptSetPermissionSchema.java: ("conceptset:%s:expression::get", "expression::get permission, specific to this conceptset with id %s"), ("conceptset:%s:version:get", "version:get permission, specific to this conceptset with id %s"), ("conceptset:%s:copy-name:get", "copy-name:get permission, specific to this conceptset with id %s")
  1. discuss the requirements to move any management of source 'read' access to the options provided in the Admin section.
@pieterlukasse
Copy link
Contributor

I would add a 3rd point:
3. safely migrate all * permissions in role 15 to their artifact-specific versions, as discussed here: #2342 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants