[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13883010#comment-13883010
]
David Webster commented on SOLR-4470:
-------------------------------------
I have to admit I find the content of this issue to be disturbing coming from
such a major Open Source project as Solr. I came here looking for a viable
security solution that did not involve segmenting off the system or otherwise
using IPsec and other IP-address centric forms of security. For most truly
Enterprise worthy solutions the products, themselves simply must address
security, internally, to ever be considered truly Enterprise worth solutions.
This product does not, and even worse, the core Dev team seems intent on NEVER
doing so!
As the lead Java architect for Distributed Systems Engineering at a fortune 100
company, security is my single most important concern. I don't care how fast a
product is, or how many slick features it has, if it isn't secure, at the core,
it is worthless as an Enterprise solution (at least for any Enterprise that
gives a whit about REAL security). Solr is doomed to use as a lab experiment
for any serious Enterprise implementation where security is more than an
afterthought.
I like Solr. I like what it does and how it does it. However, it's lack of
internal security hooks is a complete show stopper for use at my firm. So my
choices are to internalize the code, using this patch as our starting point,
and have our own Solr-like engine, or move on to something like ElasticSearch
which actually cares about real security at the node to node level.....
Also, Mavenize the damned thing! Modern projects still use Ant? I haven't
opened a build.xml script in half a decade or more....
> 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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
