[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596165#comment-13596165 ]
Per Steffensen commented on SOLR-4470: -------------------------------------- bq. We have kept security related things at the container and user level for a reason in the past - moving from that stance should require a lot of buy in. Security enforcement is still supposed to be handled by the container - that is standardized and proven technology, so of course we will not change that. But as it is today in practice you cannot configure the container to enforce security, and still have a working system - at least not a distributed/cloud system. Most organizations using distributed/cloud Solr for anything serious would want to configure the container to enforce security. This will require that Solr-nodes are able to provide credentials in requests they send to other Solr-nodes. The container is not and will never be (unless you really twist things) involved in requests going out of Solr-nodes. Providing support for having credentials in those requests going out of Solr-nodes and into other Solr-nodes is what this is all about. bq. Also, regarding the security policy - that's a no go for me. Even setting it in ant is not great - I don't want to have to pass a security policy to run my tests in eclipse I agree, but we can deal with that. Just change the realm used by the test-suite. I will be happy to do that. > 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 > Labels: authentication, https, solrclient, solrcloud, ssl > Fix For: 4.2, 5.0 > > Attachments: SOLR-4470_branch_4x_r1452629.patch, > SOLR-4470_branch_4x_r1452629.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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org