[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests

JIRA jira@apache.org

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

Alexey Serba edited comment on SOLR-4470 at 5/23/13 2:03 PM:
-------------------------------------------------------------

bq. The reasoning is that, in general you do not want a user to be able to have something done (by the subrequest) for him, that we was not allowed to do directly himself - forwarding credentials will ensure that.

[~steff1193], but -this patch  currently only does authn and not authz part- I haven't seen examples how Solr users should implement per-collection or per-document security. That's why I don't understand how someone would use "forwarding credentials" feature if Solr does not provide any way (best practices, recipes, whatever) to enforce authz policies / security.

How do you do that in your application? How do you specify who can do what? Where do you enforce that - in custom UpdateProcessor, SearchComponent, SolrDispathFilter?
               
      was (Author: alexey):
    bq. The reasoning is that, in general you do not want a user to be able to have something done (by the subrequest) for him, that we was not allowed to do directly himself - forwarding credentials will ensure that.

[~steff1193], but this patch currently only does authn and not authz part. That's why I don't understand how someone would use "forwarding credentials" feature if Solr does not provide any way (best practices, recipes, whatever) to enforce authz policies / security.

How do you do that in your application? How do you specify who can do what? Where do you enforce that - in custom UpdateProcessor, SearchComponent, SolrDispathFilter?
                 

> 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: [hidden email]
For additional commands, e-mail: [hidden email]