[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618197#comment-13618197
]
Tim Vaillancourt edited comment on SOLR-4470 at 3/31/13 1:12 AM:
-----------------------------------------------------------------
So after some more testing, I've noticed that the Authorization headers get
applied to inter-node requests ONLY when these JVM flags are added:
"-DinternalAuthCredentialsBasicAuthUsername=<username>
-DinternalAuthCredentialsBasicAuthPassword=<password>"
Without those two JVM flags the Authorization headers ARE NOT passed along on
inter-node calls. I noticed in one of Per's original posts he mentioned a
two-sided behavior where the headers are provided from the JVM properties (the
method that works for me), but also a behavior where they would be passed down
from the original Collections API call, an approach I personally like much
more. Is the later approach I mentioned working, or just not in this patch? It
currently does not work for me.
To reduce changes, simplify the problem and keep more in the container-level,
could we introduce a Limitation/Caveat that all SolrCloud nodes MUST HAVE the
same basic-auth password, and rely solely on the Collections API request to
provide the Authorization header (to be used on subrequests), vs having the
user/password in the JVM properties/app level at all?
Keep in mind that the Solr Web interface and os-level "ps" commands will
display the entire JVM command line, in this case with password plain text in
JVM command. To me Solr solely relying on the external call to provide the
credentials it is more secure, simpler and keeps Solr less involved in security
above it.
Long story short: could the ONLY approach be take the Authorization header from
the external request, applying it to subsequent inter-node ones, making this a
simpler and possibly more secure change?
was (Author: tvaillancourt):
So after some more testing, I've noticed that the Authorization headers get
applied to inter-node requests ONLY when these JVM flags are added:
"-DinternalAuthCredentialsBasicAuthUsername=<username>
-DinternalAuthCredentialsBasicAuthPassword=<password>"
Without those two JVM flags the Authorization headers ARE NOT passed along on
inter-node calls. I noticed in one of Per's original posts he mentioned a
two-sided behavior where the headers are provided from the JVM properties (the
method that works for me), but also a behavior where they would be passed down
from the original Collections API call, an approach I personally like much
more. Is the later approach I mentioned working, or just not in this patch? It
currently does not work for me.
To reduce changes, simplify the problem and keep more in the container-level,
could we introduce a Limitation/Caveat that all SolrCloud nodes MUST HAVE the
same basic-auth password, and rely solely on the Collections API request to
provide the Authorization header (to be used on subrequests), vs having the
user/password in the JVM properties/app level at all?
Keep in mind that the Solr Web interface and os-level "ps" commands will
display the entire JVM command line, in this case with password plain text in
JVM command. To me Solr solely relying on the external call to provide the
credentials it is more secure, simpler and keeps Solr less involved in security
above it.
> 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
> Labels: authentication, https, solrclient, solrcloud, ssl
> Fix For: 4.3
>
> Attachments: SOLR-4470_branch_4x_r1452629.patch,
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.patch,
> SOLR-4470.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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
