-
Notifications
You must be signed in to change notification settings - Fork 166
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
Idea : filter items shown to users in summary lists (e.g., concept sets, cohort definitions, etc) based on permissions #2222
Comments
From discussion on the Atlas WG today, some notes from discussion:
|
Adding to the previous post a couple of small items:
|
Just some clarifications: Re: read permission for entities: all WebAPI endpoints must have a permission defined, including the What @anthonysena suggests to move a 'global get' (ie: Because Atlas assumes everyone has 'global read' (that's the default configuration for Atlas Users), we never thought that we would have to provide a UI to grant read permissions but now that we have this use-case, it's something that we should think about. Side note: we are seeing that the permission payload from the serer is getting larger as more assets are defined and more permissions granted. We'd like to look at (in the 2.14 or 2.15 timeline) about optimizing or even re-thinking the permission structure so that it's faster to download and easier to process. Edit: @rkboyce beat me to it! |
Below are a few diagrams and some screen shots to help add to the specification of this feature enhancement: Permission Requirements - WebAPIBelow if a requirements diagram that has taken the current implementation and extended it to add more refined read permissions. The feature enhancement would require the addition of two new elements to the requirements:
Also, a design constraint (shown bottom right) of this feature enhancement is that global read permissions would be enabled by default but a site could enable refined read permission functionality using a configuration in the settings.xml that affects application properties. NOTE: currently, PermissionController.java PermissionService.java works in conjunction with PermissionService.java to fulfill the role of providing services to generally manage both global and individual permissions (permission_implementation in the diagram). The abstract methods for changing the read and write permissions to any entity can be found in CommonEntityDTO.java. NOTE: The specific entity (concept set, cohort definition, etc.) read and write permissions are maintained in model and service classes specific to those entities (e.g., for concept sets see ConceptSetPermissionSchema.java and ConceptSetService.java). These entity specific classes make calls to requirementDiagram
requirement permission_defined {
id: 1
text: endpoints must have a permission defined
risk: high
verifymethod: demonstration
}
functionalRequirement manage_global_permissions {
id: 1.1
text: permissions that apply to all users
risk: high
verifymethod: demonstration
}
functionalRequirement manage_individual_permissions {
id: 1.2
text: permissions that apply to any single user
risk: high
verifymethod: demonstration
}
functionalRequirement permission_service {
id: 1.3
text: permissions that apply to any single user
risk: high
verifymethod: demonstration
}
designConstraint configure_read_permissions {
id: 1.4
text: refined read permissions is optional based on configuration
risk: high
verifymethod: demonstration
}
element app_property_conf {
type: configuration element that affects application properties
docref: settings.xml
}
element global_read {
type: role with shiro template
docref: PermissionService.java
}
element global_write {
type: role with shiro template
docref: PermissionService.java
}
element author_read {
type: role with shiro template
docref: PermissionService.java
}
element author_write {
type: role with shiro template
docref: PermissionService.java
}
element permission_implementation {
type: code
docref: PermissionController.java
}
manage_global_permissions - refines -> permission_service
global_read - refines -> manage_global_permissions
global_write - refines -> manage_global_permissions
manage_individual_permissions - refines -> permission_service
author_read - refines -> manage_individual_permissions
author_write - refines -> manage_individual_permissions
permission_service - satisfies -> permission_defined
permission_implementation - contains -> permission_service
permission_service - derives -> app_property_conf
app_property_conf - satisfies -> configure_read_permissions
User experience and interface requirementsThe current (default) approach to permissions management by non-admin usersflowchart LR
A[design artifact] -->|edit| B(save)
B --> |public| D[global read]
B --> |edit| C{write access}
C -->|user| F[single user]
NOTE: In Atlas, the user can edit write access using the lock icon present in the concept set expression view: Clicking on the lock icon brings up a simple form: The revised (optional) approach to permission management by non-admin usersflowchart LR
A[design artifact] -->|edit| B(save)
B --> |edit| C{write access}
C -->|group| E[all users in a group]
C -->|user| F[single user]
B --> |edit| D{read access}
D -->|public| G[global read]
D -->|group| H[all users in a group]
D -->|user| I[single user]
NOTE: In Atlas, this could be implemented by change the modal form presented after clicking the the lock icon present in the concept set expression view to allow the user to edit both read and write access: This change could be accomplished by editing the following Atlas components and files:
|
In discussion, it was recognized that, once artifacts are filtered based on specific read permissions, users might want to make their artifacts public to all users. That would be distinct use case and will be treated in a separate issue. Also, the modal in Atlas for configuring who has read/write permissions to an artifact might be more usable if it used tabs. |
Linking to #2300 and closing out since it is complete and merged into |
Use case:
Dozens of users in a data commons are using Atlas to create concept sets and cohort definitions. Many of them are just learning how build these artifacts and some have obtained mastery. Users do want to view/browse concept sets and cohort definitions that could be useful for their analyses (reusability) but often other users would prefer that their artifacts not be listed until they give permission (e.g., because they are in draft mode or private to a project or team).
Current behavior:
All users will see up to hundreds of concept sets and cohort definitions when they click on the
#/conceptsets
and#/cohortdefinitions
endpoints in Atlas. This can be very confusing to the users as they will see numerous things that are described only by title and often with little context to help them know if its relevant to their project. They might not have a way of knowing know if the artifacts are in draft mode or have been tested. Also, many users would prefer the ability to give permission to share the viewing/listing of their artifacts with either specific individuals, groups, or the community of users as a whole. Reasons for wanting to control access include a desire to wait until the artifact is solidly tested prior to contributing it to the community, wanting the the project to be complete and published before they share the work, or other reasons.Proposal:
Modify the WebAPI to use a new property setting that will cause the WebAPI instance to return only concept sets, cohort definitions, or other artifacts (e.g., incidence rate analysis, characterizations, etc) in the response provided by endpoints such as
#/conceptsets
,#/cohortdefinitions
, etc. that a user has explicit permission to view based on the sec_role_permission and sec_permission tables in the security schema.Justification for doing this in WebAPI:
It seems more appropriate from an authorization standpoint for the service to filter artifact lists based on the authenticated user's permissions rather than having the client application (Atlas) do so. In the latter case, the client app still receives a listing that someone could sniff using developer tools within the browser. Note that if this idea is accepted, it will likely make sense to add the ability of an author to edit read permissions using Atlas "Configure access". This will add a new ability given that the current Configure Access focuses only on whom can edit an artifact.
Additional considerations:
The text was updated successfully, but these errors were encountered: