You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Ishan Chattopadhyaya (JIRA)" <ji...@apache.org> on 2016/12/06 13:19:59 UTC

[jira] [Commented] (SOLR-9513) Introduce a generic authentication plugin which delegates all functionality to Hadoop authentication framework

    [ https://issues.apache.org/jira/browse/SOLR-9513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15725467#comment-15725467 ] 

Ishan Chattopadhyaya commented on SOLR-9513:
--------------------------------------------

Sorry, it took me a while to review the patch. I think it looks good. Here are a few observations/suggestions:

# In GenericHadoopAuthPlugin, Class.forName() was used for loading the client builder. However, we've used SolrResourceLoader.newInstance() traditionally for loading resources from the classpath (for reference, see CoreContainer's initializeAuthorizationPlugin() method).
# GenericHadoopAuthPlugin implements HttpClientBuilderPlugin, and hence necessarily uses a specified client builder factory to be used for internode communication. This is fine in many cases, however this removes the possibility of using the internal PKIAuthentication for internode communication. Consider a scenario where a cluster needs to be configured to use a hadoop-auth based authentication mechanism for user < - > solr communication, but simple PKI based authentication for solr < - > solr communication.
I think we should give the users the option to use default authentication for internal communication (PKI authentication) or to use a client builder. I think what can be done is to somehow make the client builder factory optional, and use PKI based authentication where such a parameter is not passed in. This might mean that we have two concrete classes: one that implements HttpClientBuilderPlugin, one that doesn't.
# The Hadoop based tests tend to not work well on Windows. Unless you've tested on Windows and found them to be working well, I suggest lets disable them (TestSolrCloudWithHadoopAuthPlugin, TestDelegationWithHadoopAuth). Please see SOLR-9460 for reference.

> Introduce a generic authentication plugin which delegates all functionality to Hadoop authentication framework
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-9513
>                 URL: https://issues.apache.org/jira/browse/SOLR-9513
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hrishikesh Gadre
>
> Currently Solr kerberos authentication plugin delegates the core logic to Hadoop authentication framework. But the configuration parameters required by the Hadoop authentication framework are hardcoded in the plugin code itself. 
> https://github.com/apache/lucene-solr/blob/5b770b56d012279d334f41e4ef7fe652480fd3cf/solr/core/src/java/org/apache/solr/security/KerberosPlugin.java#L119
> The problem with this approach is that we need to make code changes in Solr to expose new capabilities added in Hadoop authentication framework. e.g. HADOOP-12082
> We should implement a generic Solr authentication plugin which will accept configuration parameters via security.json (in Zookeeper) and delegate them to Hadoop authentication framework. This will allow to utilize new features in Hadoop without code changes in 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