[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13665254#comment-13665254
]
Jan Høydahl commented on SOLR-4470:
-----------------------------------
bq. supporting basic auth and https primarily at the container level is much
less contraversial. [...] Nor do I want to be on the line when some big company
has a security breach due to my code changes
Correct me if I'm wrong, but all handling of security on *inbound* requests to
Solr is still handled fully by the container, even with this patch. I.e. no
code that you add to SolrCloud will be able to open a hole for accepting
incoming search requests that should not have been accepted. The user
configures the realms, user/pass etc fully on the container level.
With one exception, and that is the
{{-DinternalAuthCredentialsBasicAuthPassword=<password>}} passed to Solr code,
enabling system-initiated inter-node communication. If this is snapped up by
foreigners, they potentially gain full access to Solr if they have physical
network access. We should find a better way than passing this on the
command-line. The ultimate would be to do inter-node requests using certificate
based auth instead of passwords.
bq. If we offered this feature without the creep into all this SolrCloud code,
it would not be very contraversial
Suggestions for less creep welcome.
bq. I think ssl stuff should be working after recent http client upgrade and
switch to SystemDefaultHttpClient. Now I believe you can set up your key and
trust stores using standard Java properties and it should work.
Interesting. Let's explore further... Per?
> 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.4
>
> 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]
