Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Wed, 20 Feb 2013 16:17:14 +0000 (UTC)
From: "Per Steffensen (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12632802.1361178521555.310981.1361377034568@arcas>
In-Reply-To: <JIRA.12632802.1361178521555@arcas>
References: <JIRA.12632802.1361178521555@arcas>
Subject: [jira] [Comment Edited] (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=13582274#comment-13582274 ] 

Per Steffensen edited comment on SOLR-4470 at 2/20/13 4:16 PM:
---------------------------------------------------------------

Usually you structure URLs in you web-app by "increasing level of detail" from left to right. This way you can configure the web-container to handle the most obvious security-constraints.

Unfortunately, IMHO, Solr URLs are not structured by "increasing level of detail" - e.g. "/solr/collection1/update" should have been "/solr/update/collection1" (I consider "collection/replica" as a higher level of detail than "update"). Due to limitations on "url-pattern"s in "security-constraint|web-resource-collection"'s in web.xml (or webdefault.xml for jetty) you cannot write e.g. <url-pattern>/solr/\*/update</url-pattern>, <url-pattern>\*/update</url-pattern> or <url-pattern>\*update</url-pattern> to protect updates - it is not allowed - you can only have * in the end or as part of an extension-pattern ("*.ext" - and the . needs to be there).

Therefore it is not possible (AFAIK) to configure the web-container to protect "update"-operation or "select"-operation etc. You can configure protection on "all operations" for a specific collection (but not specific operations cross-collections), but it is much more unlikely that that is what you want to do. Or by mentioning <url-pattern>/solr/<collection-name>/update</url-pattern> for every single collection in your setup you can actually protect e.g. update, but that is not possible for those of us that have a dynamic/ever-changing set of collections.

Possible solutions from the top of my head
* 1) Make Solr URL structure "right" - e.g. "/solr/update/collection1"
* 2) Make obvious security constraints like "protecting update" or "protecting search" etc. impossible to be done by web.xml configuration, and leave it up to "programmatic protection"

I like 1) best, but is that at all feasible, or will it just be way to much work?
Since Solr is usually not something you change yourself, but something you use out-of-the-box, potentially modifying deployment-descriptors (e.g. web.xml), config files etc. 2) will really not help "the normal Solr user" and it will also be a problem figuring out exactly where to place this "programmatic protection"-code, because despite most Solr-stuff is handled by SolrDispatchFilter there are several resources that is not handled through it.

                
      was (Author: steff1193):
    Usually you structure URLs in you web-app by "increasing level of detail" from left to right. This way you can configure the web-container to handle the most obvious security-constraints.

Unfortunately, IMHO, Solr URLs are not structured by "increasing level of detail" - e.g. "/solr/collection1/update" should have been "/solr/update/collection1" (I consider "collection/replica" as a higher level of detail than "update"). Due to limitations on "url-pattern"s in "security-constraint|web-resource-collection"'s in web.xml (or webdefault.xml for jetty) you cannot write e.g. <url-pattern>/solr/\*/update</url-pattern>, <url-pattern>\*/update</url-pattern> or <url-pattern>\*update</url-pattern> to protect updates - it is not allowed - you can only have * in the end or as part of an extension-pattern ("*.ext" - and the . needs to be there).

Therefore it is not possible (AFAIK) to configure the web-container to protect "update"-operation or "select"-operation etc. You can configure protection on "all operations" for a specific collection (but not specific operations cross-collections), but it is much more unlikely that that is what you want to do. Or by mentioning <url-pattern>/solr/<collection-name>/update</url-pattern> for every single collection in your setup you can actually protect e.g. update, but that is not possible for those of us that have a dynamic/ever-changing set of collections.

Possible solutions from the top of my head
* 1) Make Solr URL structure "right" - e.g. "/solr/update/collection1"
* 2) Make obvious security constraints like "protecting update" or "protecting search" etc. impossible to be done by web.xml configuration, and leave it up to "programmatic protection"
I like 1) best, but is that at all feasible, or will it just be way to much work?
Since Solr is usually not something you change yourself, but something you use out-of-the-box, potentially modifying deployment-descriptors (e.g. web.xml), config files etc. 2) will really not help "the normal Solr user" and it will also be a problem figuring out exactly where to place this "programmatic protection"-code, because despite most Solr-stuff is handled by SolrDispatchFilter there are several resources that is not handled through it.

                  
> 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