[ https://issues.apache.org/jira/browse/SOLR-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14490669#comment-14490669 ]
Gregory Chanan commented on SOLR-7274: -------------------------------------- Some initial thoughts... {code} --- solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java (revision 1672548) +++ solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java (working copy) @@ -215,7 +215,7 @@ if (urls.size() <= 1) { String url = urls.get(0); srsp.setShardAddress(url); - try (SolrClient client = new HttpSolrClient(url, httpClient)) { + try (SolrClient client = new HttpSolrClient(url)) { ssr.nl = client.request(req); } } else { {code} Why this change? 2. Can we comment on the AuthenticationLayerPlugin? I don't think it's obvious what needs to be implemented 3. params.put("token.valid", System.getProperty("kerberos.name.rules", "30")); This doesn't look correct 4. Using "SolrClient" instead of whatever zookeeper uses (default "Client", see the code I linked above) for the jaas configuration app name will cause you to have to deal with two issues. I'm not against doing something different here, just pointing out that these problems need to be solved before you can make this change: A) kerberos tickets need to be refreshed. The zookeeper client automatically refreshes kerberos tickets, so if you just use the same configuration and app name, that's handled for you. If you want to use something different, you'll have to write code to refresh the tickets. This also means you only refresh the code when using zookeeper (i.e. SolrCloud)...you might want to pull out support for specifying the plugin via system props (so you know they have to be using solrcloud in order to read the zk props), or may want to add some error checking. B) assuming you want to use the same properties for talking to zookeeper as talking to other solr servers, you'll have to specify the jaas entry twice (once for SolrClient, once for Client or whatever zookeeper is using (ZooKeeperSaslClient.LOGIN_CONTEXT_NAME_KEY). Or you may be able to change how we handle zookeeper sasl (see SaslACLProvider, I think you'd have to write a Credentials provider?). As I said, I'm not against doing this, it just introduces additional issues for a first version. The code I linked above just uses whatever zookeeper users. 5. In HttpSolrClient.java: "postOrPut.setEntity(new BufferedHttpEntity(postOrPut.getEntity()));" Why are we always buffering the http entities? That seems like something that should be handled by the authentication plugin, i.e. usually we don't buffer. If we are using kerberos, we set up a client configurer that is smart enough to handle the http requests for that authentication scheme (here buffering is probably fine for the initial version, there are some discussions of an optimization in SOLR-6625). See this comment in SOLR-6625 for some implementation ideas https://issues.apache.org/jira/browse/SOLR-6625?focusedCommentId=14238865&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14238865 6. This doesn't seem to handle forwarding requests in the SolrDispatchFilter. There's more discussion in SOLR-6625, see here: https://issues.apache.org/jira/browse/SOLR-6625?focusedCommentId=14239957&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14239957 I don't know how to solve that without implementing SOLR-6625, though. > Pluggable authentication module in Solr > --------------------------------------- > > Key: SOLR-7274 > URL: https://issues.apache.org/jira/browse/SOLR-7274 > Project: Solr > Issue Type: Sub-task > Reporter: Anshum Gupta > Attachments: SOLR-7274.patch > > > It would be good to have Solr support different authentication protocols. > To begin with, it'd be good to have support for kerberos and basic auth. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org