[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955165#comment-13955165
]
Per Steffensen edited comment on SOLR-4470 at 3/31/14 1:37 PM:
---------------------------------------------------------------
bq. Do we really need to pass credentials around everywhere?
They really are not passed around
bq. What David Webster described sounds like a much cleaner approach?
Do you really think so!?! IMHO it sounds much more complicated. The patch to
SOLR-4470 is really very simple with respect to changes in non-test code, it
will make it very easy to setup addition of credentials to outgoing requests,
it does not require any other components than Solr running in your
infrastructure and it will not require include and config of any 3rd-party
libraries.
bq. The problem is on the Sending side (client)
This patch only deals with the sending side. With respect to doing the actual
authentication and authorization of ingoing requests it is not handled by Solr
(and probably shouldnt). As long as we run in a servlet-container (e.g. Tomcat,
but also all other certified servlet-containers) you can set up you security in
web.xml and use common LoginModules (or customize your own if you want to).
bq. That involved four lines of code in the actual SOLR code ...
This patch is not much more than those four lines, except that we support
setting up credentials in solr.xml and to "calculate credentials" given the
"super-request". Besides that just thorough testing.
bq. Now, if they ever move SOLR out of the Servlet container into a stand alone
implementation.....we have a problem with our approach, and have to take this
patch's full approach.
If they move Solr out of the servlet-container hopefully they support some
other way of setting up protection against ingoing requests. But this patch
will not help you. This issue is only about adding credentials to outgoing
requests.
was (Author: steff1193):
bq. Do we really need to pass credentials around everywhere?
They really are not passed around
bq. What David Webster described sounds like a much cleaner approach?
Do you really think so!?! IMHO it sounds much more complicated. The patch to
SOLR-4470 is really very simple with respect to changes in non-test code, it
will make it very easy to setup addition of credentials to outgoing requests,
it does not require any other components then Solr running in your
infrastructure and it will not require include and config of any 3rd-party
libraries.
bq. The problem is on the Sending side (client)
This patch only deals with the sending side. With respect to doing the actual
authentication and authorization of ingoing requests it is not handled by Solr
(and probably shouldnt). As long as we run in a servlet-container (e.g. Tomcat,
but also all other certified servlet-containers) you can set up you security in
web.xml and use common LoginModules (or customize your own if you want to).
bq. That involved four lines of code in the actual SOLR code ...
This patch is not much more than those four lines, except that we support
setting up credentials in solr.xml and to "calculate credentials" given the
"super-request". Besides that just thorough testing.
bq. Now, if they ever move SOLR out of the Servlet container into a stand alone
implementation.....we have a problem with our approach, and have to take this
patch's full approach.
If they move Solr out of the servlet-container hopefully they support some
other way of setting up protection against ingoing requests. But this patch
will not help you. This issue is only about adding credentials to outgoing
requests.
> 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: 5.0
>
> Attachments: SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch,
> SOLR-4470.patch, SOLR-4470.patch, SOLR-4470.patch, 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.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
