[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14264463#comment-14264463 ]
Per Steffensen commented on SOLR-4470: -------------------------------------- There is a variant of 2nd suggestion, that I just want to mention briefly (I am not at being brief) - something that we do of other reasons. You might want to divide your set of Solr-nodes into two sub-sets * Search-Solrs: Receiving incoming search requests from outside clients. Not containing any data themselves but orchestrating the distributed searches against the Data-Solrs * Data-Solrs: Not directly accessible (network-wise) to outside clients Setting up web-container security on Search-Solrs only might work, because they do not have to communicate with each other. And it might be enough for you if Data-Solrs are not accessible from outside. We have such a setup but not for security reasons - we have web-container security on both Search-Solrs and Data-Solrs. Just wanted to mention it because it also might make things easier for you, and since I know it is possible this is also an option for you. We do the separation because of different hardware requirements for the two kinds of Solr-nodes. Search-Solrs need more memory but almost no disk-space, Data-Solrs need more disk-space but less memory - in our setup, with the amounts and distribution of data we have and for the searches we perform against the Sor-cluster. Technically what we do is that we make a "search-collection" containing no data. "search-collection" only has shards on the Search-Solrs. Then we have several "data-collections" (containing the data) only having shards on the Data-Solrs. We have custom (not much code) SearchHandler/SearchComponents (Solr concepts) that basically just calculates the "data-collection" you have to search and forwards the search from outside clients to "search-collection" to those "data-collections". We have an advanced algorithm for calculating the "data-collections" that has to be searches given the concrete search to "search-collection", but you can just always calculate "all data-collections". This way Search-Solrs handle the distributed search, while Data-Solrs handle searches against local shard only. This is kinda the same as putting your own custom gateway in front of your Solr-nodes, and make the Solrs-nodes inaccessible directly from outside clients. We just use Solr itself as this front gateway, taking advantage of all the nice features - high availability (with more than one Search-Solr) etc. Clients uses CloudSolrServer, but always make searches against the "search-collection". > 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: 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 > 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.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org