[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13665214#comment-13665214
]
Mark Miller commented on SOLR-4470:
-----------------------------------
bq. I'll prepare a VOTE thread on the dev list for a) Should SolrCloud support
auth/https
I don't think that's really the question - supporting basic auth and https
primarily at the container level is much less contraversial. If devs don't
really have to consider that stuff (and right now you really don't), that's one
things. When devs are put on the line when it comes to users and security,
thats another thing.
It's the code creep into Solr to support this feature that concerns me. If we
offered this feature without the creep into all this SolrCloud code, it would
not be very contraversial. I realize the reasons there is the creep, I've read
the comments, but I still see it as moving over a line we have purposely not
crossed before.
The real question is if we want to push down this security support road - where
we advertise this support and developers are on the line for this support. It's
both a fuzzy line and a slippery slope - but this issue seems to be moving us
down a path I'm not so comforatable with when I consider any future dev I put
into SolrCloud.
SolrCloud is still at an early enough phase that I'm not really willing to
spend a lot of time considering security as I add new features or refactor
older code. Nor do I want to be on the line when some big company has a
security breach due to my code changes. We get around this by saying Solr needs
to be protected at a level above Solr - can you setup some basic auth at the
container level and run most things over https? Sure, I suppose that's
convienent for some - but we don't claim any security - we say it's up to you
to sandbox Solr.
> 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]
