You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hrishikesh Gadre (JIRA)" <ji...@apache.org> on 2017/10/24 21:05:00 UTC

[jira] [Created] (SOLR-11543) Support fine grained authorization for multi-tenancy usecases

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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org