Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-9513

Introduce a generic authentication plugin which delegates all functionality to Hadoop authentication framework

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.4, 7.0
    • Component/s: None
    • Security Level: Public (Default Security Level. Issues are Public)
    • Labels:
      None

      Description

      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.

      1. SOLR-9513_6x.patch
        92 kB
        Hrishikesh Gadre
      2. SOLR-9513.patch
        132 kB
        Ishan Chattopadhyaya
      3. SOLR-9513-deprecate-GenericHadoopAuthPlugin.patch
        11 kB
        Ishan Chattopadhyaya

        Issue Links

          Activity

          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user hgadre opened a pull request:

          https://github.com/apache/lucene-solr/pull/114

          SOLR-9513 A generic Solr authentication plugin to integrate with Hadoop

          • Added a generic Solr authentication plugin to integrate with Hadoop
          • Added delegation tokens support
          • Added proxy users support

          Currently the unit tests are using kerberos authentication handler in
          Hadoop. After Solr is updated to use Hadoop 3, these tests will be
          modified to use multi-auth support in Hadoop.

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/hgadre/lucene-solr SOLR-9513_fix

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/lucene-solr/pull/114.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #114


          commit 7562e0cecfc758aff4399909ef147114813204f8
          Author: Hrishikesh Gadre <hgadre@cloudera.com>
          Date: 2016-11-08T21:18:34Z

          SOLR-9513 A generic Solr authentication plugin to integrate with Hadoop

          • Added a generic Solr authentication plugin to integrate with Hadoop
          • Added delegation tokens support
          • Added proxy users support

          Currently the unit tests are using kerberos authentication handler in
          Hadoop. After Solr is updated to use Hadoop 3, these tests will be
          modified to use multi-auth support in Hadoop.


          Show
          githubbot ASF GitHub Bot added a comment - GitHub user hgadre opened a pull request: https://github.com/apache/lucene-solr/pull/114 SOLR-9513 A generic Solr authentication plugin to integrate with Hadoop Added a generic Solr authentication plugin to integrate with Hadoop Added delegation tokens support Added proxy users support Currently the unit tests are using kerberos authentication handler in Hadoop. After Solr is updated to use Hadoop 3, these tests will be modified to use multi-auth support in Hadoop. You can merge this pull request into a Git repository by running: $ git pull https://github.com/hgadre/lucene-solr SOLR-9513 _fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/114.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #114 commit 7562e0cecfc758aff4399909ef147114813204f8 Author: Hrishikesh Gadre <hgadre@cloudera.com> Date: 2016-11-08T21:18:34Z SOLR-9513 A generic Solr authentication plugin to integrate with Hadoop Added a generic Solr authentication plugin to integrate with Hadoop Added delegation tokens support Added proxy users support Currently the unit tests are using kerberos authentication handler in Hadoop. After Solr is updated to use Hadoop 3, these tests will be modified to use multi-auth support in Hadoop.
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya Can you please take a look?

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya Can you please take a look?
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya any updates?

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya any updates?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Apologies, it escaped my attention. I shall be able to review this early next week.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Apologies, it escaped my attention. I shall be able to review this early next week.
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Great thanks for reviewing this

          Show
          hgadre Hrishikesh Gadre added a comment - Great thanks for reviewing this
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

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

          1. 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).
          2. 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.
          3. 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.
          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - 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.
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya Thanks for the review. I have addressed all the comments and updated the PR. Can you please take a look?

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya Thanks for the review. I have addressed all the comments and updated the PR. Can you please take a look?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Hrishikesh Gadre, I think the patch looks good. However, I'm slightly concerned about the names for the two plugins, i.e. SolrCloudHadoopAuthPlugin and GenericHadoopAuthPlugin. Given that both can be used in SolrCloud, I think it will be confusing for the user as to why are these named so. Do you think we can choose some other names that make the actual distinction clear? Perhaps something like (a) HadoopAuthPlugin and HadoopAuthWithPKIPlugin, or (b) HadoopAuthWithInterNodeAuthPlugin and HadoopAuthPlugin. I'm open to other suggestions as well.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Hrishikesh Gadre , I think the patch looks good. However, I'm slightly concerned about the names for the two plugins, i.e. SolrCloudHadoopAuthPlugin and GenericHadoopAuthPlugin . Given that both can be used in SolrCloud, I think it will be confusing for the user as to why are these named so. Do you think we can choose some other names that make the actual distinction clear? Perhaps something like (a) HadoopAuthPlugin and HadoopAuthWithPKIPlugin , or (b) HadoopAuthWithInterNodeAuthPlugin and HadoopAuthPlugin . I'm open to other suggestions as well.
          Hide
          markrmiller@gmail.com Mark Miller added a comment -

          +1

          Show
          markrmiller@gmail.com Mark Miller added a comment - +1
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya How about

          GenericHadoopAuthPlugin --> can be used with standalone Solr as well as Solrcloud with PKI auth for internode communication
          ConfigurableInternodeAuthHadoopPlugin --> extends from GenericHadoopAuthPlugin and allows you to configure internode auth scheme (useful only in Solrcloud).

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya How about GenericHadoopAuthPlugin --> can be used with standalone Solr as well as Solrcloud with PKI auth for internode communication ConfigurableInternodeAuthHadoopPlugin --> extends from GenericHadoopAuthPlugin and allows you to configure internode auth scheme (useful only in Solrcloud).
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          GenericHadoopAuthPlugin and ConfigurableInternodeAuthHadoopPlugin sound fine. Just as an aside, I was wondering if we can drop "Generic" as well; but I leave it to your judgement.
          However, I would prefer to refrain from highlighting (while documenting) the distinction between standalone and SolrCloud too much. I think both are potentially useful in standalone, since there can be internode communication even in non-SolrCloud/standalone setups (during master/slave replication).

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - GenericHadoopAuthPlugin and ConfigurableInternodeAuthHadoopPlugin sound fine. Just as an aside, I was wondering if we can drop "Generic" as well; but I leave it to your judgement. However, I would prefer to refrain from highlighting (while documenting) the distinction between standalone and SolrCloud too much. I think both are potentially useful in standalone, since there can be internode communication even in non-SolrCloud/standalone setups (during master/slave replication).
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Hrishikesh, if you can update your pull request with the names you suggested or put a patch here, I can commit this.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Hrishikesh , if you can update your pull request with the names you suggested or put a patch here, I can commit this.
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya I have updated the PR. Can you please take a look?

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya I have updated the PR. Can you please take a look?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Looks good. I've attached the patch here for reference and plan to commit shortly.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Looks good. I've attached the patch here for reference and plan to commit shortly.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit a1a8b2864e621c18aa86b21d4a244233e991a47d in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a1a8b28 ]

          SOLR-9513: Generic Hadoop authentication plugins, GenericHadoopAuthPlugin and ConfigurableInternodeAuthHadoopPlugin

          Show
          jira-bot ASF subversion and git services added a comment - Commit a1a8b2864e621c18aa86b21d4a244233e991a47d in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a1a8b28 ] SOLR-9513 : Generic Hadoop authentication plugins, GenericHadoopAuthPlugin and ConfigurableInternodeAuthHadoopPlugin
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Hrishikesh Gadre, do you have a moment to please backport this to branch_6x? Unless you get to it first, I can do this, but later in the week.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Hrishikesh Gadre , do you have a moment to please backport this to branch_6x? Unless you get to it first, I can do this, but later in the week.
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya Yes I will submit a 6x patch later today.

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya Yes I will submit a 6x patch later today.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user hgadre closed the pull request at:

          https://github.com/apache/lucene-solr/pull/114

          Show
          githubbot ASF GitHub Bot added a comment - Github user hgadre closed the pull request at: https://github.com/apache/lucene-solr/pull/114
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya Here is the patch for branch_6x

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya Here is the patch for branch_6x
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 791b8bc6bfde2197e52ab01d8ef0feea6e9838b7 in lucene-solr's branch refs/heads/branch_6x from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=791b8bc ]

          SOLR-9513: Generic Hadoop authentication plugins, GenericHadoopAuthPlugin and ConfigurableInternodeAuthHadoopPlugin

          Show
          jira-bot ASF subversion and git services added a comment - Commit 791b8bc6bfde2197e52ab01d8ef0feea6e9838b7 in lucene-solr's branch refs/heads/branch_6x from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=791b8bc ] SOLR-9513 : Generic Hadoop authentication plugins, GenericHadoopAuthPlugin and ConfigurableInternodeAuthHadoopPlugin
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Thanks Hrishikesh Gadre!

          There's a test failure [0], due to the test introduced here, on Java 9 and Windows. I don't think the test code is faulty, there could be some issue with the test runner setup. The mailing list thread is here [1] (FYI, Uwe Schindler).

          [0] - https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18574/
          [1] - http://lucene.472066.n3.nabble.com/JENKINS-EA-Lucene-Solr-master-Linux-32bit-jdk-9-ea-147-Build-18573-Still-Unstable-td4310502.html

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Thanks Hrishikesh Gadre ! There's a test failure [0] , due to the test introduced here, on Java 9 and Windows. I don't think the test code is faulty, there could be some issue with the test runner setup. The mailing list thread is here [1] (FYI, Uwe Schindler ). [0] - https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18574/ [1] - http://lucene.472066.n3.nabble.com/JENKINS-EA-Lucene-Solr-master-Linux-32bit-jdk-9-ea-147-Build-18573-Still-Unstable-td4310502.html
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 21a6fc3d763d2eedf665e13474b9f751301c738b in lucene-solr's branch refs/heads/branch_6x from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=21a6fc3 ]

          SOLR-9513: Fix test failure on Windows and Java9 by avoiding NPE in tearDownClass()

          Show
          jira-bot ASF subversion and git services added a comment - Commit 21a6fc3d763d2eedf665e13474b9f751301c738b in lucene-solr's branch refs/heads/branch_6x from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=21a6fc3 ] SOLR-9513 : Fix test failure on Windows and Java9 by avoiding NPE in tearDownClass()
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit b5cfb17bd0d56da03dbe1f179db0f03ea0acf735 in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b5cfb17 ]

          SOLR-9513: Fix test failure on Windows and Java9 by avoiding NPE in tearDownClass()

          Show
          jira-bot ASF subversion and git services added a comment - Commit b5cfb17bd0d56da03dbe1f179db0f03ea0acf735 in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b5cfb17 ] SOLR-9513 : Fix test failure on Windows and Java9 by avoiding NPE in tearDownClass()
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited

          As I was working on the Ref Guide changes for this, I realized a confusing potential mistake has crept in. We have a GenericHadoopAuthPlugin class and a HadoopAuthPlugin class, both almost exact copies of each other. I guess this happened while trying to rename the plugin names at the time of updating the PR [0], and I didn't notice at the time of commit.

          The tests are based on HadoopAuthPlugin, and we already have an RC for 6.4 out (and this is not important enough to hold up the release).

          Assuming my observations are correct and I'm not missing something, I propose the following now:

          1. We go forward documenting the HadoopAuthPlugin (and the ConfigurableInternodeAuthHadoopPlugin).
          2. We deprecate the GenericHadoopAuthPlugin, in favour of HadoopAuthPlugin.

          Hrishikesh Gadre, what do you think? I'm attaching a patch (master) for this proposed change, which we can commit using another issue (since this one is already potentially released as it is part of 6.4 RC). SOLR-9984.

          [0] - https://github.com/apache/lucene-solr/pull/114.patch

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited As I was working on the Ref Guide changes for this, I realized a confusing potential mistake has crept in. We have a GenericHadoopAuthPlugin class and a HadoopAuthPlugin class, both almost exact copies of each other. I guess this happened while trying to rename the plugin names at the time of updating the PR [0] , and I didn't notice at the time of commit. The tests are based on HadoopAuthPlugin, and we already have an RC for 6.4 out (and this is not important enough to hold up the release). Assuming my observations are correct and I'm not missing something, I propose the following now: We go forward documenting the HadoopAuthPlugin (and the ConfigurableInternodeAuthHadoopPlugin). We deprecate the GenericHadoopAuthPlugin, in favour of HadoopAuthPlugin. Hrishikesh Gadre , what do you think? I'm attaching a patch (master) for this proposed change, which we can commit using another issue (since this one is already potentially released as it is part of 6.4 RC). SOLR-9984 . [0] - https://github.com/apache/lucene-solr/pull/114.patch
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya I think documenting just the HadoopAuthFilter is a good idea. But instead of deprecating it, I think we should just delete that class for following reasons,

          • This class is not directly interacting with client applications. Hence if some deployments are using this class, we can just ask them to change the security.json to point to HadoopAuthFilter (which will provide identical functionality).
          • Deprecating a class has a hugh cost in the long term. e.g. if there are any API changes - we will still have to update this class. Also we will need to remember the fact that this class needs to be deleted at some point etc.

          If deleting a class is not an option, why can't we spin another RC for 6.4 ? This functionality has very little or no interaction with the rest of the system. Hence just deleting it before the release seems like the right thing to do.

          CC Jim Ferenczi

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya I think documenting just the HadoopAuthFilter is a good idea. But instead of deprecating it, I think we should just delete that class for following reasons, This class is not directly interacting with client applications. Hence if some deployments are using this class, we can just ask them to change the security.json to point to HadoopAuthFilter (which will provide identical functionality). Deprecating a class has a hugh cost in the long term. e.g. if there are any API changes - we will still have to update this class. Also we will need to remember the fact that this class needs to be deleted at some point etc. If deleting a class is not an option, why can't we spin another RC for 6.4 ? This functionality has very little or no interaction with the rest of the system. Hence just deleting it before the release seems like the right thing to do. CC Jim Ferenczi
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya Yet another option may be to deprecate GenericHadoopAuthPlugin and have it extend HadoopAuthPlugin. That way the cost of having GenericHadoopAuthPlugin would be essentially 0.

          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya Yet another option may be to deprecate GenericHadoopAuthPlugin and have it extend HadoopAuthPlugin. That way the cost of having GenericHadoopAuthPlugin would be essentially 0.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          If deleting a class is not an option, why can't we spin another RC for 6.4 ?

          I think it is too much effort for little value.

          Yet another option may be to deprecate GenericHadoopAuthPlugin and have it extend HadoopAuthPlugin.

          Exactly what I tried to do in the patch here (also attached to SOLR-9984). If you can please review the patch, I'll commit it. This doesn't require us to re-spin.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - If deleting a class is not an option, why can't we spin another RC for 6.4 ? I think it is too much effort for little value. Yet another option may be to deprecate GenericHadoopAuthPlugin and have it extend HadoopAuthPlugin. Exactly what I tried to do in the patch here (also attached to SOLR-9984 ). If you can please review the patch, I'll commit it. This doesn't require us to re-spin.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -
          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Hrishikesh Gadre , Cassandra Targett , can you please review the ref guide page [0] I added? [0] - https://cwiki.apache.org/confluence/display/solr/Hadoop+Authentication+Plugin
          Hide
          hgadre Hrishikesh Gadre added a comment -

          Ishan Chattopadhyaya Thanks for the writeup !

          Here are couple of improvements,

          • Instead of
          It must be noted that it is possible that the authentication configurations changes across Solr versions, depending
          upon the version of Hadoop used within Solr and also as per the Hadoop authentication library's release cycle and
          feature changes. If you require a more stable setup, in terms of configuration, ability to perform rolling upgrades,
          backward compatibility etc., you could choose some of the other supported authentication plugins.
          

          How about

          Please note that the version of Hadoop library used by Solr is upgraded periodically. While Solr will ensure the
          stability and backwards compatibility of the structure of the plugin configuration (viz. the parameter names of this
          plugin), the values of these parameters may change based on the version of Hadoop library. Please review the
          Hadoop documentation for the version used by your Solr installation for more details.
          
          For some of the authentication schemes (e.g. kerberos), Solr provides a native implementation of authentication
          plugin. If you require a more stable setup, in terms of configuration, ability to perform rolling upgrades,
          backward compatibility etc., you should consider using such plugin. Please review _link_to_top_level_solr_auth_doc
          for more details.
          
          Show
          hgadre Hrishikesh Gadre added a comment - Ishan Chattopadhyaya Thanks for the writeup ! Here are couple of improvements, Can we add the configuration of proxy users in the examples? You can take a look at following snippet for reference, https://github.com/apache/lucene-solr/blob/a2131a9e1e3a22dec3ab2185c06999edac3e2f73/solr/core/src/test/org/apache/solr/security/hadoop/TestImpersonationWithHadoopAuth.java#L61 Instead of It must be noted that it is possible that the authentication configurations changes across Solr versions, depending upon the version of Hadoop used within Solr and also as per the Hadoop authentication library's release cycle and feature changes. If you require a more stable setup, in terms of configuration, ability to perform rolling upgrades, backward compatibility etc., you could choose some of the other supported authentication plugins. How about Please note that the version of Hadoop library used by Solr is upgraded periodically. While Solr will ensure the stability and backwards compatibility of the structure of the plugin configuration (viz. the parameter names of this plugin), the values of these parameters may change based on the version of Hadoop library. Please review the Hadoop documentation for the version used by your Solr installation for more details. For some of the authentication schemes (e.g. kerberos), Solr provides a native implementation of authentication plugin. If you require a more stable setup, in terms of configuration, ability to perform rolling upgrades, backward compatibility etc., you should consider using such plugin. Please review _link_to_top_level_solr_auth_doc for more details.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited

          Changed as per your second suggestion. Will check the proxy users example on Monday. Thanks.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited Changed as per your second suggestion. Will check the proxy users example on Monday. Thanks.

            People

            • Assignee:
              ichattopadhyaya Ishan Chattopadhyaya
              Reporter:
              hgadre Hrishikesh Gadre
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development