[
https://issues.apache.org/jira/browse/SOLR-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877453#comment-16877453
]
Ishan Chattopadhyaya commented on SOLR-13472:
---------------------------------------------
The problem here was:
1. node_2 doesn't have a replica for test collection.
2. As a result, the permissions that have been set couldn't be validated.
3. The "all" permission here was claimed by "admin", and hence this request was
falsely marked MatchStatus.FORBIDDEN.
What should've happened is:
If node receiving the request doesn't host a replica, it should check if
"forwardCredentials" is set to true (BasicAuthPlugin supports this), and mark
MatchStatus.NO_PERMISSION_FOUND, so that the request isn't rejected right away,
but validated properly on a forwarded node.
> 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
> Components: Authorization
> Affects Versions: 7.7.1, 8.0
> Reporter: adfel
> Assignee: Ishan Chattopadhyaya
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
