[
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: [email protected]
For additional commands, e-mail: [email protected]
