You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Jason Gerlowski (JIRA)" <ji...@apache.org> on 2019/05/15 21:07:00 UTC

[jira] [Commented] (SOLR-13472) HTTP requests to a node that does not hold a core of the collection are unauthorized

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

Jason Gerlowski commented on SOLR-13472:
----------------------------------------

I haven't tried out your example yet, so I can't speak to what is causing the behavior you're seeing.  I hope to look into it soon.

But I can offer one point of clarification on why the behavior might differ in SolrJ vs a curl request.  I suspect what's happening is that your SolrJ code makes use of CloudSolrClient.  CloudSolrClient is data-aware for collections, meaning that it makes requests directly to the nodes hosting your data (saving users some extra hops).  So if the behavior is only triggered when a request arrives at a node that _doesnt_ host your data, it makes sense that SolrJ (or at least CloudSolrClient) is unable to trigger it.

> HTTP requests to a node that does not hold a core of the collection are unauthorized
> ------------------------------------------------------------------------------------
>
>                 Key: SOLR-13472
>                 URL: https://issues.apache.org/jira/browse/SOLR-13472
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Authorization
>    Affects Versions: 7.7.1, 8.0
>            Reporter: adfel
>            Priority: Minor
>              Labels: security
>
> When creating collection in SolrCloud, collection is available for queries and updates through all Solr nodes, in particular nodes that does not hold one of collection's cores. This is expected behaviour that works when using SolrJ client or HTTP requests.
> When enabling authorization rules it seems that this behaviour is broken for HTTP requests:
>  - executing request to a node that holds part of the collection (core) obey to authorization rules as expected.
>  - other nodes respond with code 403 - unauthorized request.
> SolrJ still works as expected.
> Tested both with BasicAuthPlugin and KerberosPlugin authentication plugins.
> +Steps for reproduce:+
> 1. Create a cloud made of 2 nodes (node_1, node_2).
> 2. Configure authentication and authorization by uploading following security.json file to zookeeper:
>  
> {code:java}
> {
>  "authentication": {
>    "blockUnknown": true,
>    "class": "solr.BasicAuthPlugin",
>    "credentials": {
>      "solr": "'solr' user password_hash",
>      "indexer_app": "'indexer_app' password_hash",
>      "read_user": "'read_user' password_hash"
>    }
>  },
>  "authorization": {
>    "class": "solr.RuleBasedAuthorizationPlugin",
>    "permissions": [
>      {
>        "name": "read",
>        "role": "*"
>      },
>      {
>        "name": "update",
>        "role": [
>          "indexer",
>          "admin"
>        ]
>      },
>      {
>        "name": "all",
>        "role": "admin"
>      }
>    ],
>    "user-role": {
>      "solr": "admin",
>      "indexer_app": "indexer"
>    }
>  }
> }{code}
>  
> 3. create 'test' collection with one shard on *node_1*.
> -- 
> The following requests expected to succeed but return 403 status (unauthorized request):
> {code:java}
> curl -u read_user:read_user "http://node_2/solr/test/select?q=*:*"
> curl -u indexer_app:indexer_app "http://node_2/solr/test/select?q=*:*"
> curl -u indexer_app:indexer_app "http://node_2/solr/test/update?commit=true"
> {code}
>  
> Authenticated '_solr_' user requests works as expected. My guess is due to the special '_all_' role.



--
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