You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Per Steffensen (JIRA)" <ji...@apache.org> on 2014/02/17 21:06:23 UTC
[jira] [Updated] (SOLR-4470) Support for basic http auth in
internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Per Steffensen updated SOLR-4470:
---------------------------------
Attachment: SOLR-4470_trunk_r1568857.patch
[~janhoy] asked me to help making a patch fitting trunk. Find attached SOLR-4470_trunk_r1568857.patch fitting revision 1568857 of trunk (today).
Changes in this patch from the top of my head
* Cleaned up so that much less changes are necessary in test-space
** Introduced manipulateRequest on SolrServers. Currently only used in tests, but guess it is a nice little thing to have in general to make code that gets the chance to modify any request that goes through a certain SolrServer
** And introduced TestSolrServers.TestXXXSolrServer’s to be used in all tests (where you run with security set up on the Solr-nodes) - they make sure to add correct credentials to outgoing requests from the test-methods themselves. Remember that this SOLR-4470 is not very much about clients being able to penetrate the security-layer of a web-container by providing correct credentials - it is about Solr-node-to-Solr-node requests also being able to do so. (It would be nice to use TestXXXSolrServers in all tests, because it is nice to have such a place to add test-only stuff, but for now introduced for tests running with security added on their jettys)
* SecurityDistributedTest is now green ([~janhoy] struggled with that). Had to hook into StreamingSolrServers introducing interface SolrServerFactory and set it from SecurityDistributedTest in order to catch the exceptions to assert on. I believe it is a fail that SolrCmdDistributor does not report errors back to client - see the FIXME in SolrCmdDistributor
* By code-inspection alone (I have not tested it) I found an error in StreamingSolrServers - see the FIXME in StreamingSolrServers. Because I have not tested it, I am not sure that what I write in the FIXME is true, but I cannot see why it should not be
* Authentication credentials provider factories (pluggable components to provide credentials for Solr-node-to-Solr-node requests) is now configurable in solr.xml like this (maybe some would like to have it in cluster-properties instead, but that change should be trivial to make later)
{code}
<security>
<interSolrNodeRequestAuthCredentialsProviderFactories>
<directSubRequest>
<str name="class">org.apache.solr.security.UseSuperRequestAuthCredentialsSubRequestFactory</str>
</directSubRequest>
<internalRequest>
<str name="class">org.apache.solr.security.SystemPropertiesAuthCredentialsInternalRequestFactory</str>
</internalRequest>
</interSolrNodeRequestAuthCredentialsProviderFactories>
</security>
{code}
Would like to have made it like below instead, but this thing about int, str etc. seem to be the way it is done here (when in Rome… I guess)
{code}
<directSubRequest class=“org.apache.solr.security.UseSuperRequestAuthCredentialsSubRequestFactory”/>
{code}
* I have tried running tests to verify that the entire test-suite is green after my patch, but I simply cannot make an entire test-suite-run green, but I cannot do that without the patch either. But I am pretty sure tests do not become “more red” by this patch. Have run a lot of partial tests.
> Support for basic http auth in internal solr requests
> -----------------------------------------------------
>
> Key: SOLR-4470
> URL: https://issues.apache.org/jira/browse/SOLR-4470
> Project: Solr
> Issue Type: New Feature
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Assignee: Jan Høydahl
> Labels: authentication, https, solrclient, solrcloud, ssl
> Fix For: 4.7
>
> Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch, SOLR-4470_trunk_r1568857.patch
>
>
> We want to protect any HTTP-resource (url). We want to require credentials no matter what kind of HTTP-request you make to a Solr-node.
> It can faily easy be acheived as described on http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes also make "internal" request to other Solr-nodes, and for it to work credentials need to be provided here also.
> Ideally we would like to "forward" credentials from a particular request to all the "internal" sub-requests it triggers. E.g. for search and update request.
> But there are also "internal" requests
> * that only indirectly/asynchronously triggered from "outside" requests (e.g. shard creation/deletion/etc based on calls to the "Collection API")
> * that do not in any way have relation to an "outside" "super"-request (e.g. replica synching stuff)
> We would like to aim at a solution where "original" credentials are "forwarded" when a request directly/synchronously trigger a subrequest, and fallback to a configured "internal credentials" for the asynchronous/non-rooted requests.
> In our solution we would aim at only supporting basic http auth, but we would like to make a "framework" around it, so that not to much refactoring is needed if you later want to make support for other kinds of auth (e.g. digest)
> We will work at a solution but create this JIRA issue early in order to get input/comments from the community as early as possible.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org