lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Chanan (JIRA)" <>
Subject [jira] [Commented] (SOLR-7274) Pluggable authentication module in Solr
Date Sat, 11 Apr 2015 01:05:12 GMT


Gregory Chanan commented on SOLR-7274:

Some initial thoughts...

--- solr/core/src/java/org/apache/solr/handler/component/	(revision 1672548)
+++ solr/core/src/java/org/apache/solr/handler/component/	(working copy)
@@ -215,7 +215,7 @@
           if (urls.size() <= 1) {
             String url = urls.get(0);
-            try (SolrClient client = new HttpSolrClient(url, httpClient)) {
+            try (SolrClient client = new HttpSolrClient(url)) {
      = client.request(req);
           } else {
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("", "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) 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 "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

6.  This doesn't seem to handle forwarding requests in the SolrDispatchFilter.  There's more
discussion in SOLR-6625, see here:
I don't know how to solve that without implementing SOLR-6625, though.

> Pluggable authentication module in Solr
> ---------------------------------------
>                 Key: SOLR-7274
>                 URL:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message