[
https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585093#comment-13585093
]
Per Steffensen commented on SOLR-4470:
--------------------------------------
Prepare for a new feature well covered by test with the following testing
strategy
* 1) We run with "a common security setup" in most (all tests inheriting from
BaseDistributedSearchTestCase) distributed/cloud tests
* 2) There will be a new distributed/cloud test focusing on error-scenarios
around security - authentication/authorization errors when you do not provide
correct credentials
I chose 1) because
* I believe it is the easiest/best way to make sure support for A&A is correct
in all inter-solr-node communication
* It would increase time-to-run-test-suite a lot if I was going to introduce
new A&A focused tests for all inter-solr-node communications
(search/update/get-sub-requests, collection-API-sub-requests,
recovery-sub-request etc.)
* If we introduce a new feature requiring new inter-solr-node communication it
is likely that it will inherit from BaseDistributedSearchTestCase (including
security setup out-of-the-box), and therefore "remind" the developer to
remember to provide correct credentials for the inter-solr-node requests
involved.
I added 2) because we with 1) will have good coverage of cases where you
provide "good" credentials in inter-solr-node communication, but the reason it
works might be because security was somehow not enabled or working correctly.
Therefore added error-scenarios making sure security is enabled and working, by
asserting on authentication/authorization errors when you provide "bad or none"
credentials.
"Common security scheme" being
* A search-user that is only allowed to do selects/gets
* An update-user that is only allowed to do updates
* An all/admin-user that is allowed to do everything
* You are not allowed to do anything without providing credentials
> 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: Bug
> Components: clients - java, multicore, replication (java), SolrCloud
> Affects Versions: 4.0
> Reporter: Per Steffensen
> Labels: authentication, solrclient, solrcloud
> Fix For: 4.2
>
>
> 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]
