lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anshum Gupta (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-7275) Pluggable authorization module in Solr
Date Wed, 15 Apr 2015 22:21:59 GMT

     [ 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

Patch for just the framework. It includes the following changes:

* All security config now goes into /security.json. Here's a sample:
{code}
{"authorization":
  {"class":"solr.SimpleSolrAuthorizationPlugin",
  "deny":["user1","user2"]
  }
}
{code}
Everything from the {{authorization}} section would be passed on to the authorization plugin.
* After a discussion with Noble, it made more sense to restrict the access at this point to
what's required and if we feel the need to expose zkStateReader, zkClient or the coreContainer
itself to the plugin, we could do that at a later time. For now, all configuration for the
plugin should just go into the authorization section.
* SimpleSolrAuthorizationPlugin is no longer in the direct scope of this issue, but I created
a new issue for that. I'll put up the updated patch, that doesn't use the coreContainer or
access zk directly right after posting this patch.
* I tried to have the SolrAuthorizationPlugin extend MapInitializedPlugin but that was more
invasive than required as it takes a Map<String, String> whereas we need a Map<String,
Object> here. I'll see if there's a way to do that without being invasive or duplicating
a lot of the code so it still just extends PluginInfoInitialized.

Here are the steps to test this patch:
1. Start zk.
2. Using zk CLI, 
{noformat}set /security.json {"authorization":{"class":"solr.SimpleSolrAuthorizationPlugin","deny":["user1","user2"]}}{noformat}
Change the userlist to whatever you want to use to test.
3. Start SolrCloud, make sure you use the zk server/ensemble you just setup.
e.g. {noformat}bin/solr start -z localhost:2181 -c{noformat}

To write your own plugin:
# Extend SolrAuthorizationPlugin, this requires implementing 
## init(PluginInfo info) : This is called when the node comes up. It is called once and creates
the plugin object. This is where you can define your connections to 3rd party security systems
etc.
## authorize(SolrRequestContext context) and optionally overriding 
# Follow the steps above (testing this patch) and specify the FQN of the implementation class
in the authorization{{class}}. e.g.
{code}
{"authorization":{"class":"solr.MyCustomSolrAuthorizationPlugin","connect_string":"hostname:port/somepath"}}
{code}

Still todo:
* Work on the context object.
* Cleanup/shutdown hook.
* Reloading/watching for changes in the /security.json file or documenting how to change it.
* Tests

> 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-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


Mime
View raw message