[RFC]: Seeking details on the Workspace experience & access control

[mnkugler]

The idea of “Projects” or “Workspaces” was recently posted in Dashboards. This is a request for feedback and input on the details for the Workspace concept.

Workspaces help organize your work, library items/saved objects, and tools, and is a convenient way to enable sharing and collaboration between users. It’s also a way to customize the tools that are available, so that when users switch between workspace, they have a focused view of the features and tools that are relevant for the selected workspace.

Actions you should be able to do with workspaces and objects:

1. View library items that exist in the workspace (Note: "saved objects" could be renamed as "library items" in the UI)
2. See data that your credentials give you access to when you enable a data connection in the workspace. (i.e. for data sources with embedded credentials or data sources using pass-through or individually managed credentials)
3. See any cluster-owned objects (for example, alerts, monitors, detectors, etc) that your credentials give you permission to see.
4. Make it easier for users to share visualizations and other library objects and collaborate in the workspace

Sharing experience
For sharing permissions, depending on your credentials, you can assign permissions based on individual users, or user groups. Dashboard Admins will have permissions to do anything in dashboards and configure permissions for other users. Workspace admins can configure the user permissions and the settings, as well as have CRUD permissions for workspaces. As a Dashboards user, you will be able to switch between workspaces as well.

• “Sharing” means granting access to a dashboard or visualization, and edits happen to the shared dashboard or visualization
• "Copy" means create a new object(dashboard/visualization etc) in another workspace, the new object’s content should be the same as the original one. Any change to one of the objects won’t affect the other.

Open question: How can we handle access control if we abstract the saved object repository?
Today we have a target architecture for abstracting saved objects in Dashboards so that we can decouple an OpenSearch-Dashboard cluster from an OpenSearch cluster.

However this target architecture lacks an explanation of how to handle access control for saved objects. Today for a user who depends on the security dashboard plugin, the tenant concept handles this in a rough way, with some gaps. How can we modify our architecture to handle this in a more straightforward way, with access controls built into the architecture, rather than as a side effect of tenants?

[AmiStrn]

I think the concept of organizing my personal space on the application is key here, and it sounds great!
Though, I worry that by combining the workspace concept with the sharing (access control) concept we may slow down the time-to-release of this feature.
Perhaps the sharing part can be separated and dealt with under a Security enhancement?

[wbeckler]

That's a great point. I'd be curious how the sharing concept would work, and if it could fix the issue of not being able to share objects across tenants without copy-pasting json.

[zengyan-amazon]

I have a design proposal for this workspace access control and posted it at #4633 , please feel free to comment on it

[jgough]

Thank you for putting together the proposal. A replacement for Tenants was discussesd previously in opensearch-project/security#1869 and there may be some discussion from that that may aid direction here.

My main issue with the previous proposal seemed to be around the lack of compartmentalisation, that is being able to split up my visualisations into different places rather than seeing them all jumbled up in one big list. It sounds like Workspaces as proposed would keep the same sort of compartmentalisation that Tenants provides so that sounds good to me.

[peternied]

FYI @mnkugler it looks like Workspace would be in a good position to handle this feature request [1] to expose more access control information to users.

• [1] [Feature] Show / hide menu entries based on user permissions security-dashboards-plugin#857

[xluo-aws]

Workspace admin can config which features are visible in the workspace but it's different than show/hide menu based on user permissions because everyone in the workspace still see the same menu entries. I guess the challenge is how to map plugin permissions with menu entries.

[markdboyd]

Just checking in here. opensearch-project/security-dashboards-plugin#857 was closed to refer to this issue, however does the design proposal for workspace access control (#4633) address the need for restricting access to some parts of OpenSearch Dashboards for non-admins? It seems more focused on managing access to saved objects, but I could be wrong