lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <>
Subject [jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
Date Thu, 04 Dec 2014 19:53:14 GMT


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
* 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:
>             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
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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message