Read access considerations - Managing sources access and correcting permission templates
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 151
- Forks
- 183
- Avg merge
- 14m
- Merged PRs (30d)
- 2
Description
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 (https://github.com/OHDSI/WebAPI/pull/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:
- 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")
- discuss the requirements to move any management of source 'read' access to the options provided in the Admin section.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing pull request #2342 and the permission schema changes in src/main/java/org/ohdsi/webapi/security/model/CohortDefinitionPermissionSchema.java and ConceptSetPermissionSchema.java. Test the retained permission-template entries, then clarify the requirements for managing source read access through Atlas's Admin section. Done means the desired template permissions are verified and the source-access management approach is agreed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- authorization, backend, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100