lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Steffensen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-4470) Support for basic http auth in internal solr requests
Date Sat, 23 Feb 2013 11:28:13 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message