[
https://issues.apache.org/jira/browse/SOLR-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440754#comment-17440754
]
Gus Heck edited comment on SOLR-15776 at 11/9/21, 5:17 AM:
-----------------------------------------------------------
I think any linking/coupling of the UI to specific permissions is bad. Our
existing permissions system has at least two confusing ways it differs from
most other systems I've encountered (its allow by default rather than deny by
default, and the role/permission lookup is backwards). Furthermore our list of
permissions is eclectic and inconsistent with some permissions relying on
"read" or "update" for the permissions while others have the name of the
permission embedded in (i.e. "security-edit").
I would be more enthusiastic about moving the UI to work like AWS where the
widget that needs a given call simply says "not permitted" if the data call
behind it fails. Then the UI can easily adapt to any permissions system because
all it has to react to is the 403 response.
On my ever growing list of things I would do if could find time/funding is
adding a plugin that uses a much more well tested system written by folks who's
main focus is security (such as Apache Shiro) and then advocate that we ditch
our "role our own security" implementation. This change is something that would
need to be undone... and do we know if this change is compatible with setups
other than the stock RBAC and basic auth setup?
Edit: If done with Shiro, permissions would look like
Collection:read:collection1 (Type:action:id) And Collection:read:* for read
all collections, and Collection:*:collection1 for any action on collection1 etc.
was (Author: gus_heck):
I think any linking/coupling of the UI to specific permissions is bad. Our
existing permissions system has at least two confusing ways it differs from
most other systems I've encountered (its allow by default rather than deny by
default, and the role/permission lookup is backwards). Furthermore our list of
permissions is eclectic and inconsistent with some permissions relying on
"read" or "update" for the permissions while others have the name of the
permission embedded in (i.e. "security-edit").
I would be more enthusiastic about moving the UI to work like AWS where the
widget that needs a given call simply says "not permitted" if the data call
behind it fails. Then the UI can easily adapt to any permissions system because
all it has to react to is the 403 response.
On my ever growing list of things I would do if could find time/funding is
adding a plugin that uses a much more well tested system written by folks who's
main focus is security (such as Apache Shiro) and then advocate that we ditch
our "role our own security" implementation. This change is something that would
need to be undone... and do we know if this change is compatible with setups
other than the stock RBAC and basic auth setup?
Edit: If done with Shiro, permissions would look like
Collection:read:collection1 (Type:action:id)
> Make Admin UI play well with Authorization
> ------------------------------------------
>
> Key: SOLR-15776
> URL: https://issues.apache.org/jira/browse/SOLR-15776
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Authorization
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Major
> Attachments: Skjermbilde 2021-11-07 kl. 21.43.58.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Admin UI does not really know about what the current logged in user should
> have access to and not, and it just throws some error messages if you attempt
> to do stuff you are not authorized to. The upcoming SOLR-11623 will also add
> further permissions to some APIs that are commonly used from admin UI.
> I propose that we do the following:
> * Add to /admin/info/system a list of predefined permissions that the
> logged-in user has assigned (now we only list the roles)
> * Admin UI will always require permissions {{{}config-read{}}},
> {{core-read}} and {{{}coll-read{}}}. If either the /admin/info/system call
> fails or the three permissions are not present, the Admin UI shows a message
> "You do not have sufficient permissions to use the Admin UI"
> See the attached matrix ([or google
> spreadsheet|https://docs.google.com/spreadsheets/d/1s2xokDxw9IkXr7ZA5n06RPDj6EwvpbsZ7zUeKpvRC3Q/edit?usp=sharing])
> of permissions required for each section of the Admin UI. Use this matrix to
> restrict access to various Admin UI screens or buttons, depending on user's
> permissions:
> * Cloud/Tree/Graph: Disable if not {{zk-read}}
> * Schema-designer: Stop probing with ajax call, check permission list instead
> * Documents tab: Disable the whole tab or only the "Submit document" button
> if not {{update}} permission
> * Query/Stream/SQL/Schema: Disable tabs or buttons if not {{read}} permission
> * Schema: Disable buttons if not {{schema-edit}} permission
> * Core overview: Disable if not {{health}} and {{read}} permissions
> * Ping: Disable if not {{health}} permission
> * Plugin/Stats & Segments-info: Disable if not {{metrics-read}} permission
> [~thelabdude] ping
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
