[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13665157#comment-13665157 ]

Jan Høydahl commented on SOLR-4470:
-----------------------------------

I have also been on the "Stay out of security" line all the time, and I think that's one of the benefits with being hosted in a servlet container - folks know how to setup auth/ssl and it will also work with Solr. And if there's a security hole then *they* must fix it :)

However, noone have constructively suggested how to make these auth/ssl setups work with *SolrCloud* without changes in Solr.

We can tell large users to deploy their search cluster on a separate secure network behind firewalls. But for every large customer there are 50 medium ones, with 2 or 3 Solr nodes in the same network as their Sharepoint or whatever. The only way they can lock things down is setting up firewall rules on every Solr node, allowing traffic from frontend IPs and the IPs of the other Solr nodes. This is a partial workaround but you can still not use basic auth or encryption, and communication would still be open for packet sniffing, something which is a no-starter for healthcare and other sensitive data.

That's why I have become +1 on supporting this specific use case and even put some work in maintaining it.
               

> 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: [hidden email]
For additional commands, e-mail: [hidden email]