[
https://issues.apache.org/jira/browse/SOLR-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17446548#comment-17446548
]
Jan Høydahl commented on SOLR-15776:
------------------------------------
{quote}I think what you are suggesting is that when a user loads up the Admin
UI, one of the calls from the front end to the back is to an API that returns
all the user permissions?
{quote}
Yes, see current PR, it already adds that to info/system response along with
the users roles.
{quote}Some sort of big permissions JSON structure that communicates what you
can and can't do?
{quote}
I haven't fleshed out exactly that permission checking logic. The easiest is
for the js code to issue calls like {{isPermitted(permissions.COLL_EDIT_PERM)}}
knowing what backend permissions are required for e.g. a screen to actually
work for the user. But if we instead do {{isPermitted("GET",
"/admin/zookeeper")}} to de-couple from actual permissions, then we need to
create a map from each path/method pair to permission names as well. Another
de-coupling would be to create an enum of all screens/features, and do
{{isPermitted(features.SECURITY_SCREEN, "READ")}} or
{{{}isPermitted(features.COLLECTIONS_SCREEN, "WRITE"){}}}, and then map them to
needed permission(s) somewhere.
Frankly, i'd rather go with the straight backend-permissions and not try to be
clever and predict the future, or inject another source of bugs. The
permissions map pretty cleanly to screens and buttons as proven in the
spreadsheet, and even if there will be many checks to update if we change
security framework, I think the sum of work is still smaller by implementing a
minimal KISS solution now.
> Make Admin UI play well with Authorization
> ------------------------------------------
>
> Key: SOLR-15776
> URL: https://issues.apache.org/jira/browse/SOLR-15776
> Project: Solr
> Issue Type: Improvement
> 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
