[jira] [Updated] (SOLR-7275) Pluggable authorization module in Solr

["Anshum Gupta (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anshum Gupta updated SOLR-7275:
-------------------------------
    Attachment: SOLR-7275.patch

Here's the first patch. This introduces the following:
1. SolrAuthorizationPlugin interface - The interface that would need to be implemented for custom security plugins e.g. Ranger/Sentry/...
2. Configuration mechanism for security - /security.json in zoo keeper.
3. SolrRequestContext - HttpHeader, UserPrincipal etc. I'm working on extracting more context from the request e.g. Collection, handler, etc. and populate those in here.

Usage:
To try this out, you need to add /security.json node in zk, with the following data format
{code}
{"class":"solr.SimpleSolrAuthorizationPlugin"}
{code}

Also, access rules (black list for now) goes into /simplesecurity.json
{code}
{"blacklist":["user1","user2"]}
{code}

This uses the http param (uname) to filter out/authorize requests. 
The following request would then start returning 401:
http://localhost:8983/solr/techproducts/select?q=*:*&wt=json&uname=user1

NOTE: The authorization plugin doesn't really do anything about inter-shard communication (and doesn't propagate the user principal), it can be used only for black listing right now. You could write a plugin that sets up IP based rules or I could add those rules to the plugin that would be shipped out of the box to support white listing of User info + IP information.


To summarize, I'm still working on the following:
1. Extract more information and populate the context object.
2. Have a watch on the access rules file. I'm still debating between a watch vs having an explicit RELOAD like call that updates the access rules.
3. Support IP and/or user based whitelist.


> Pluggable authorization module in Solr
> --------------------------------------
>
>                 Key: SOLR-7275
>                 URL: https://issues.apache.org/jira/browse/SOLR-7275
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Anshum Gupta
>            Assignee: Anshum Gupta
>         Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and return an {{SolrAuthorizationResponse}} object. The object as of now would only contain a single boolean value but in the future could contain more information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to understand Solr's capabilities e.g. how to extract the name of the collection or other information from the incoming request as there are multiple ways to specify the target collection for a request. Similarly request type can be specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific security systems e.g. Apache Ranger or Sentry. It would keep all the security system specific code out of Solr.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org