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

Mark Miller commented on SOLR-4470:
-----------------------------------

bq. auth by simply configuring the servlet container 

Right - nothing to do with Solr code.

bq. But with SolrCloud, Solr needs to be aware of this.

Right - now we are talking about Solr code - my point exactly.

bq. we talk about an overhead of one extra argument or code line per the 
request.

No, I don't think that is the only overhead at all in terms of further 
SolrCloud developement.

bq. We shold not defer useful, solid features like this to a distant 
Solr-as-non-webapp release!

It depends on the feature - to me, I'm not so sure this feature worth putting 
Solr code into the security game. I think  it should be handled above Solr.

My current inclination would be to veto the code change unless other Solr 
(especially those that work on SolrCloud) developers show support for getting 
into the security game. Solr has explicity avoided it for a reason - it changes 
what we are responsible for. It's no longer leaving things up to the container 
and above - it puts developers on the line. 

bq. "Move Solr forward!"

I'm not in agreemeant that its a big step forward, and I'm not convinced it's 
worth pulling security into Solr code.
                
> 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
>            Assignee: Jan Høydahl
>              Labels: authentication, https, solrclient, solrcloud, ssl
>             Fix For: 4.4
>
>         Attachments: SOLR-4470_branch_4x_r1452629.patch, 
> SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r1454444.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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to