[BUG] Read only user cannot create Short URL's

[luizportela]

Describe the bug

When using a read-only user, a http403 error happens when trying to create a Short URL, with the message: Unable to create short URL. Error:

To Reproduce
Steps to reproduce the behavior:

1. Duplicate the role kibana_user to kibana_user_global_ro
2. On the role kibana_user_global_ro add an index permission for the index "*" with get, read, search,suggest permissions.
3. On the role kibana_user_global_ro add a global_tenant read only permission.
4. Associate the user with the roles kibana_user_global_ro and kibana_read_only
5. Go to OpenSearch Dashboards Discover, Share, and select Short URL

Expected behavior

Read-only users should be able to navigate and use the Short URL feature without the need for a tenant write permission.

OpenSearch Version
1.0

Dashboards Version
1.0.0

Plugins

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

Screenshots

[kavilla]

Hello @luizportela,

Thanks for opening this! Creating the short URL does a write operation to the system index to store the URL. However, the security plugin prevents write operations to the system index for read only users.

Will re-route to the security dashboards plugin repo but might be a substantial amount of work to enable short url creation for read only users.

Thanks again!

[DarshitChanpura]

Thanks for opening this! Creating the short URL does a write operation to the system index to store the URL. However, the security plugin prevents write operations to the system index for read only users.

This is an expected behavior of security plugin.

[jimishs]

I believe this a side effect of how short URLs are generated (by writing to a protected index). I believe we should consider to support this for readonly users by improving the implementation to meet the needs of the user.

I am also open to hearing reasons on why we should not support this for readonly users.

@elfisher @ahopp would appreciate any insights. Thanks

[elfisher]

What should the expectations of the user be here? I would think if the user it was shared with has permissions to the objects loaded in the page, then the URL should be loadable by that user.

[jimishs]

@elfisher The URL itself is loadable, but the issue is with current implementation for creating a share saved object short URL link, which seems to check if a user has write permissions to the tenant index, in order to generate a shareable URL. I think the user experience we should strive for is - If a user has permissions to view an object, they should also be able to generate a shareable short URL to the same. Note that when the receiving user clicks on the shareable link, they still need to authenticate to Dashboards, but the shared link acts like a bookmark that will take them straight to this dashboard or whatever other saved object is being shared.

Happy to hear any different views as well.

[elfisher]

@elfisher The URL itself is loadable, but the issue is with current implementation for creating a share saved object short URL link, which seems to check if a user has write permissions to the tenant index, in order to generate a shareable URL. I think the user experience we should strive for is - If a user has permissions to view an object, they should also be able to generate a shareable short URL to the same. Note that when the receiving user clicks on the shareable link, they still need to authenticate to Dashboards, but the shared link acts like a bookmark that will take them straight to this dashboard or whatever other saved object is being shared.

Happy to hear any different views as well.

That makes sense and sounds reasonable. @kavilla and @davidlago I'd love to get your thoughts on what the right way forward is to enable this experience.

[peternied]

Possible Mitigation

While this doesn't fix the root problem of allowing generation of shorted URLs, I think it might make sense to alter the rendering behavior to prevent the short URL UX to appear when it would result in failure.

When generation the context menu there is a flag from the capabilities provider [1] that is used to check if short urls should be possible or not, e.g allowShortUrl: uiCapabilities.discover.createShortUrl, if the capabilities were intercepted and altered based on the a user's read-only vs read-write access to the tenant I think this would prevent read only users from hitting this incomplete scenario.

Resolution of the root issue

I know there has been discussion around the technical reason this isn't done, but that technical reasons are tied to security configuration within the cluster. The Dashboards index stored within OpenSearch backend is a proxy to the index data. This doesn't allow for nuance such as, allow writing to specifics documents and not other documents. In order to handle this scenario more sensibly decoupling the Dashboards data from the backend is needed. Workspace [2] is a new effort to decouple the access control model of the OpenSearch backend from the Dashboards features

• [1] Capabilities Provider https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/discover/server/capabilities_provider.ts
• [2] Workspace RFC [RFC]: Seeking details on the Workspace experience & access control OpenSearch-Dashboards#4615

[MaciejMierzwa]

Hi, since I started looking into it, I talked with @kajetan-nobel who is working on the parent task: opensearch-project/security#2701. It seems like this short_url task could be done in the scope of the parent one. Here's the PR:
https://github.com/opensearch-project/OpenSearch-Dashboards/pull/4498/files#diff-11afec5e134a00ee3d5860652aa06d2c6cd6b0e2e3c54d0110a1c64eba1dd8d4R41-R45

EDIT: Issue seems to still exist

[MaciejMierzwa]

Here's PR: opensearch-project/OpenSearch-Dashboards#5539
It doesn't fully utilize the solution mentioned in comment #891 (comment) by Peter. Let me know what do you think

[MaciejMierzwa]

Closing as issue was resolved in scope of different task: opensearch-project/OpenSearch-Dashboards#5539 (comment)