Hrishikesh Gadre created SOLR-11543:
---------------------------------------
Summary: Support fine grained authorization for multi-tenancy
usecases
Key: SOLR-11543
URL: https://issues.apache.org/jira/browse/SOLR-11543
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 5.2
Reporter: Hrishikesh Gadre
As part of SOLR-7275, we implemented a pluggable authorization framework for
Solr. But the current design (specifically wrt to admin apis) is not quite
suitable to support multi-tenant Solr cloud in a secure environment. In such
environment, there are two types of system admins (a) admins belonging to the
service provider and (b) admins belonging to an individual tenant.
Type (a) admins are responsible to setup solr cluster e.g. setting up solr
servers, managing security etc.
Type (b) admins on the other hand are responsible to perform collection-level
admin operations e.g. creating/deleting/configuring/reloading collections
belonging to the tenant. From security perspective it is important to ensure
that such admin is able to operate only on the collections belonging to the
respective tenant.
The current design of authorization framework has following limitations
(a) it does not provide the resource names associated with the operation as
part of the authorization context (Ref:
https://github.com/apache/lucene-solr/blob/ef7b525123fc32b0703f1579c2422957d1b0a2ab/solr/core/src/java/org/apache/solr/security/PermissionNameProvider.java).
Here the collection names are hard-coded to either null or "*" value in the
parameter for Name instance. This results in providing global admin privileges
to the user. In a multi-tenant environment, this is not acceptable.
(b) The authorization framework assumes that only a single permission is
necessary for any given operation (Ref:
https://github.com/apache/lucene-solr/blob/ef7b525123fc32b0703f1579c2422957d1b0a2ab/solr/core/src/java/org/apache/solr/security/PermissionNameProvider.java#L77).
For some of the admin operations (e.g. MIGRATE collections admin API) we need
to check additional permissions for multi-tenancy. Specifically in case of
MIGRATE API we need to check following permissions
- collections admin privilege (Update)
- collection privilege for the source collection (Read)
- collection privilege for the destination collection (Update)
Hence ideally PermissionNameProvider needs to return a list of permission names
instead of a single permission (in most cases the list will contain a single
element).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
