Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 21 Feb 2013 11:50:14 +0000 (UTC)
From: "Per Steffensen (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12632802.1361178521555.316902.1361447414385@arcas>
In-Reply-To: <JIRA.12632802.1361178521555@arcas>
References: <JIRA.12632802.1361178521555@arcas>
Subject: [jira] [Commented] (SOLR-4470) Support for basic http auth in
 internal solr requests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583131#comment-13583131 ] 

Per Steffensen commented on SOLR-4470:
--------------------------------------

bq. So let this issue deal with authentication - if you have access then you have access to all - and make another jira for authorization

Basically yes! The decision on who can be authenticated and to what they can be authorized, is not the focus of this jira. It is up to the admins of the Solr cluster to setup/program that. This jira is about what credentials a solr-node will add to the requests it sends itself to other solr-nodes.

Joggling with authentication/authorization setups is actually more of a matter in the tests I make in the solr-test-suite, where I want to make a more "normal" kind of setup:
* a search-user that can do searches only
* an update-user that can do updates only
* an admin-user that is allowed to do everything

This cannot be achieved by configuring the web-container. You need to do programmatic authorization. I will figure out whether I will
* 1) go for the above user/authorization wrt tests
* 2) or if I will make another cut where different users have access to do stuff on different limited sets of collections
The thing is that a solr-node makes requests to another solr-node in A LOT of different places, and to make sure it all works I would really not want to make a protection-focused test-suite that basically tests everything (search, update, collection-creation/deletion, peer-sync, recovery etc.) again - but just with protection added. I would rather apply protection to the existing cloud/distributed test-suite (to make pretty sure every kind of solr-to-solr-request case is covered), and doing that will be much easier with 1) and 2).
                
> 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