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