You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hrishikesh Gadre (JIRA)" <ji...@apache.org> on 2018/07/07 17:28:00 UTC
[jira] [Commented] (SOLR-12514) Rule-base Authorization plugin
skips authorization if querying node does not have collection replica
[ https://issues.apache.org/jira/browse/SOLR-12514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16535851#comment-16535851 ]
Hrishikesh Gadre commented on SOLR-12514:
-----------------------------------------
[~mahesh.kumar.vs]
{quote}Thanks for sharing the process details, I'll keep that in mind for future reference. Is there an official page with the process?
{quote}
Here is the info : [https://www.apache.org/security/]
[~noble.paul]
{quote}There should be no need to handle a per implementation handling in security framework. If we go down this rabbit hole, this is going to be a nightmare. if we implement a solution, it should be universal to all authorization providers.
{quote}
Yes I didn't upload the patch with the intent of committing. This is just a reference to show how this has been solved with Hadoop auth plugin. I see two options being discussed here,
(a) Forward the original request as is (i.e. to keep all the original HTTP headers intact etc.).
(b) Change the behaviour of Solr request forwarding logic to return 302 response
With option (a) we will be implementing a generalised version of "proxy users" functionality in Hadoop. With option (b) we will be making a backwards incompatible change in the Solr behaviour since solrj is not the only client that talks to Solr. So we should exercise some caution with option (b).
> Rule-base Authorization plugin skips authorization if querying node does not have collection replica
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-12514
> URL: https://issues.apache.org/jira/browse/SOLR-12514
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
> Affects Versions: 7.3.1
> Reporter: Mahesh Kumar Vasanthu Somashekar
> Priority: Major
> Attachments: SOLR-12514.patch, Screen Shot 2018-06-24 at 9.36.45 PM.png, security.json
>
>
> Solr serves client requests going throught 3 steps - init(), authorize() and handle-request ([link git-link|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.3.1/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L471]).
> init() initializes all required information to be used by authorize(). init() skips initializing if request is to be served remotely, which leads to skipping authorization step ([link git-link|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.3.1/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L291]).
> init() relies on 'cores' object which only has information of local node (which is perfect as per design). It should actually be getting security information (security.json) from zookeeper, which has global view of the cluster.
>
> Example:
> SolrCloud setup consists of 2 nodes (solr-7.3.1):
> live_nodes: [
> "localhost:8983_solr",
> "localhost:8984_solr",
> ]
> Two collections are created - 'collection-rf-1' with RF=1 and 'collection-rf-2' with RF=2.
> Two users are created - 'collection-rf-1-user' and 'collection-rf-2-user'.
> Security configuration is as below (security.json attached):
> "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "permissions":[
> { "name":"read", "collection":"collection-rf-2", "role":"collection-rf-2", "index":1}
> ,
> { "name":"read", "collection":"collection-rf-1", "role":"collection-rf-1", "index":2}
> ,
> { "name":"read", "role":"*", "index":3}
> ,
> ...
> "user-role":
> { "collection-rf-1-user":[ "collection-rf-1"], "collection-rf-2-user":[ "collection-rf-2"]}
> ,
> ...
>
> Basically, its setup to that 'collection-rf-1-user' user can only access 'collection-rf-1' collection and 'collection-rf-2-user' user can only access 'collection-rf-2' collection.
> Also note that 'collection-rf-1' collection replica is only on 'localhost:8983_solr' node, whereas ''collection-rf-2' collection replica is on both live nodes.
>
> Authorization does not work as expected for 'collection-rf-1' collection:
> $ curl -u collection-rf-2-user:password 'http://*localhost:8983*/solr/collection-rf-1/select?q=*:*'
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
> <title>Error 403 Unauthorized request, Response code: 403</title>
> </head>
> <body><h2>HTTP ERROR 403</h2>
> <p>Problem accessing /solr/collection-rf-1/select. Reason:
> <pre> Unauthorized request, Response code: 403</pre></p>
> </body>
> </html>
> $ curl -u collection-rf-2-user:password 'http://*localhost:8984*/solr/collection-rf-1/select?q=*:*'
> {
> "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":0,
> "params":{
> "q":"*:*"}},
> "response":{"numFound":0,"start":0,"docs":[]
> }}
>
> Whereas authorization works perfectly for 'collection-rf-2' collection (as both nodes have replica):
> $ curl -u collection-rf-1-user:password 'http://*localhost:8984*/solr/collection-rf-2/select?q=*:*'
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
> <title>Error 403 Unauthorized request, Response code: 403</title>
> </head>
> <body><h2>HTTP ERROR 403</h2>
> <p>Problem accessing /solr/collection-rf-2/select. Reason:
> <pre> Unauthorized request, Response code: 403</pre></p>
> </body>
> </html>
> $ curl -u collection-rf-1-user:password 'http://*localhost:8983*/solr/collection-rf-2/select?q=*:*'
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
> <title>Error 403 Unauthorized request, Response code: 403</title>
> </head>
> <body><h2>HTTP ERROR 403</h2>
> <p>Problem accessing /solr/collection-rf-2/select. Reason:
> <pre> Unauthorized request, Response code: 403</pre></p>
> </body>
> </html>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org