[
https://issues.apache.org/jira/browse/SOLR-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17441012#comment-17441012
]
Jan Høydahl commented on SOLR-15776:
------------------------------------
The permissions are a mess, true. But it's what we have, and it would be very
transparent and obvious in UI code to hide/show parts of the UI based on
permissions. Any Authorization impl needs to work with our set of predefined
permissions, even if it is not necessarily role-based. Cause all our handlers
and APIs are tagged with what permission it requires. So until we rip out the
whole backend system and replace it with something else, we're stuck with these
permissions. And by the time such a rewrite is ready (11.0 - 12.0?) there may
very well be a new Admin UI as well to go along with it. Or worst case, we need
to rewrite what permissions the UI checks for.
So while this is a stop-gap, I feel it is far better than having the UI hammer
even more "probing" requests to the backend than it already does. On every
single menu menu click in the current Admin we already spawn a set of requests,
e.g. for logging tab:
{code:java}
/admin/cores
/admin/info/system
/admin/collections&action=LIST
/admin/collections&action=LISTALIASES
/admin/info/logging
/schema-designer/configs {code}
The last call there to /schema-designer/configs is a "probe" call like you talk
about, simply to check if user has access to schema designer. But the only
thing that probe call does is to check that the user has permission
{{{}config-edit{}}}, which could be done statically after reading the list of
permissions from /admin/info/system. Such a check is not sufficient either,
since the schema designer needs {{{}read{}}}, {{{}update{}}}, {{schema-edit}}
etc in addition. So if we go 100% the probe-route, every menu choice in the
admin UI would spawn 15 requests to solr just to probe permissions...
And how would you test ahead of time whether a users has permission to create a
collection in order to decide whether the button should be active or not? By
issuing a CREATE call? By adding another action or endpoint?
> 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
