[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234548#comment-14234548
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
Thanks for participating [~zoomieia1980]!!!
I am not sure you really understand what my patch is about. It ONLY deals with
adding credentials to outgoing requests in order to be able to penetrate a
security-layer on the server-side. This is necessary if you choose to somehow
put a security-layer between the Solr client and the Solr server. This patch
has NOTHING to do with setting up that security-layer around the server.
Webcontainers do that very well for you. And if Solr really want to move away
from being a webapplication that has to run in a webcontainer, there are
numerous other frameworks out there that you can use to set up a security-layer
around your server. But this patch has nothing to do with how you add that
security-layer around your server. You keep talking about JAAS LoginModules
etc. and they really are concepts belonging in this security-layer around the
server - thats why I believe you do not completely follow my patch.
Changing the SolrJ client so that it adds "hardcoded" credentials to all
outgoing requests is really just a few lines around the HTTPClient-usage that
you talk about. In this area, my patch really is not more than those few lines,
except that I support doing it at several levels
* Setting up the credentials once and for all on HTTPClient level, so that it
will add those credentials to all requests sent through it
* Doing the same on SolrJ XXXSolrServer (clients) level - basically doing it on
the HTTPClients of the HTTPSolrServers used directly or underneath more
complicated XXXSolrServers like CloudSolrServer
* It also supports setting credentials on request-level, allowing you to use
different credentials for different requests sent through the same HTTPClient,
without having to change the "global" credentials on HTTPClient level
But all of this is not that many lines of code
The thing is, that in a Cloud setup, the Solr server itself is a Solr client,
sending requests to other Solr servers. If there is a security-layer between
the Solr servers (and there will be if you use e.g. webcontainer managed
security) you need to somehow tell the Solr servers which credentials to add to
its outgoing requests targeting other Solr servers. My patch is a lot about
this aspect. You can fairly easily make in a way so that it just always uses
the same "hardcoded" credentials on those outgoing requests. But you might want
to configure those fixed credentials from the outside. What if you actually
want to use different credentials depending on the kind of the outgoing
request. What if the outgoing request is actually triggered from an incoming
request, do you want to use the credentials from the ingoing request on the
outgoing request? E.g. if an outside client sends a distributed query R1 to
Solr server A, Solr server A has to send sub-requests R2 to Solr server B -
should it copy the credentials from R1 to R2 or should it use
configured/hardcoded credentials from Q2?
You might have very different "algorithms" for Solr servers to decide on
credentials for the requests it sends to other Solr servers. In some cases the
Solr server might need to fetch the credentials from an outside agency, or you
might have a handshake/negotiating-step (like SOLR-6625) or something. Most of
the non-test-code in my patch is about making "the component that calculates
credentials for requests going out of Solr servers" pluggable.
But most of the patch is actually test-code. I tend to want to test my stuff
thoroughly. In Solr tests we start actual Solr servers sending real requests to
each other. So why not test this entire thing by setting up webcontainer
managed security in the embedded jetty-containers running the Solr servers in
test. Some of the code joggles those things.
> 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: Trunk
>
> 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.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
