Securing Solr: Practical Use Case

Application security is the general practice of adding features or functionality to software to prevent a range of different threats. These include denial of service attacks and other cyber attacks, and data breaches or data theft situations. Lucidworks Fusion built on top of Solr strengthening many aspects, indexing, querying, and adding new effective features like in-built ML / AI-based recommenders, etc. The aspect Fusion really empowers Solr is security. Please check out the following links to know more: Secure Fusion: Single sign-on, Secure Fusion: Fusion authentication and authorization

Apache Solr, itself, though not very user-friendly, has security frameworks for supporting authentication and authorization of users. Solr includes some plugins out of the box, and additional plugins can be developed using the authentication and authorization frameworks listed on: Authentication and Authorization Plugins.

There are a couple of very well written articles by Noble Paul and Kevin Cowan on Lucidworks blog site for Securing Solr:
Securing Solr: Basic Auth Permission Rules
Securing Solr: Tips and Tricks You Really Need to Know

In this article, we will be discussing configuring roles to control user access to the system via Rule-Based Auth Plugin and a real-life use-case.

Use-case: In Solrcloud, we wish to implement access control to a group of users with different permissions.

  • The first group would be “admin” who would have access to each and everything in and around Solr.
  • The second group would be “DevOps” which would have the same permissions as “admin” except cannot alter permissions for an existing group or add a new group altogether.
  • The third group would be “dev” who have query access to all collections, neither write permissions nor read access to configurations of the collections.


We would be explaining each command following and how we concluded to have that command itself and not anything else.

1. Upload security.json to zookeeper of the Solr cluster, sample can be found on the official documentation:

“blockUnknown”: true,
“credentials”:{“admin”:”IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=”}

Assume solr directory to be SOLR_HOME:

$SOLR_HOME/server/scripts/cloud-scripts/ -cmd putfile /security.json /path/to/security.json

Please note the default password on the above security.json is “SolrRocks”, we can update the password in the next step. Also, the ‘admin’ user is mapped to ‘admin’ role.

2. Update the ‘admin’ user password using curl from the terminal, here we do “iamadmin”:

curl — user admin:SolrRocks http://localhost:8983/solr/admin/authentication -H ‘Content-type:application/json’ -d ‘{“set-user”: {“admin”:”iamadmin”}}’

3. Set respective roles to respective users, ‘dev’ user to ‘dev’ role, ‘build’ user to ‘build’ role, using curl from the terminal:

curl -u admin:iamadmin -H ‘Content-type:application/json’ -d ‘{“set-user-role” : {“dev”: “dev”}}’ http://localhost:8983/solr/admin/authorization

curl -u admin:iamadmin -H ‘Content-type:application/json’ -d ‘{“set-user-role” : {“build”: “build”}}’ http://localhost:8983/solr/admin/authorization

4. Configure respective users to their respective passwords using curl from the terminal:

curl — user admin:iamadmin http://localhost:8983/solr/admin/authentication -H ‘Content-type:application/json’ -d ‘{“set-user”: {“dev”:”iamdev”}}’

curl — user admin:iamadmin http://localhost:8983/solr/admin/authentication -H ‘Content-type:application/json’ -d ‘{“set-user”: {“build”:”iambuilder”}}’

Following we start to configure permissions to respective roles, ‘dev’, ‘build’, and ‘admin’. Please check out the Rule-based Authorization Plugin to see the available embedded permissions.

Important things to keep in mind while designing Solr security via rule-based authorization plugin:

a. Assigning permission for a specific embedded one available or request handler can be done once in the entire security.json, you have to make sure all the appropriate roles are mapped to unique permission once in the entire security file.

b. Always start with assigning permissions with maximum available roles suited.

5. Setting all the required permissions for ‘dev’ role and hence keeping in mind point #b and taking the entire superset of roles:

curl — user admin:iamadmin -H ‘Content-type:application/json’ -d ‘{
“set-permission”: {“name”: “collection-admin-read”, “role”:[“build”,”admin”,”dev”]},
“set-permission”: {“name”: “read”, “role”:[“build”,”admin”,”dev”]},
“set-permission”: {“name”: “core-admin-read”, “role”:[“build”,”admin”,”dev”]},
“set-permission”: {“name”: “schema-read”, “role”:[“build”,”admin”,”dev”]},
“set-permission”: {“name”: “config-read”, “role”:[“build”,”admin”,”dev”]},
}’ http://localhost:8983/solr/admin/authorization

Setting permissions for ‘build’ and ‘admin’ and restricting access to only stated roles, and hiding from ‘dev’ role:

6. Restricting access of collection configurations to ‘build’ and ‘admin’ only, ‘dev’ shouldn’t have access:

curl — user admin:iamadmin -H ‘Content-type:application/json’ -d ‘{
“set-permission”: {“collection”: null,
“role”: [“build”,”admin”]}
}’ http://localhost:8983/solr/admin/authorization

curl — user admin:iamadmin -H ‘Content-type:application/json’ -d ‘{
“set-permission”: {“collection”: “*”,
“role”: [“build”,”admin”]}
}’ http://localhost:8983/solr/admin/authorization

curl — user admin:iamadmin -H ‘Content-type:application/json’ -d ‘{
“set-permission”: {“collection”: “*”,
“role”: [“build”,”admin”]}
}’ http://localhost:8983/solr/admin/authorization

7. Restricting access of updating documents via dataimport handler to ‘build’ and ‘admin’ only, ‘dev’ shouldn’t have access:

curl — user admin:iamadmin -H ‘Content-type:application/json’ -d ‘{
“set-permission”: {“collection”: “*”,
“role”: [“build”,”admin”]}
}’ http://localhost:8983/solr/admin/authorization

8. Restricting all edit capabilities along with updating documents to collections to ‘build’ and ‘admin’ only, and hide/restrict from ‘dev’ role.

curl — user admin:iamadmin -H ‘Content-type:application/json’ -d ‘{
“set-permission”: {“name”: “collection-admin-edit”, “role”:[“build”,”admin”]},
“set-permission”: {“name”: “update”, “role”:[“build”,”admin”]},
“set-permission”: {“name”: “schema-edit”, “role”:[“build”,”admin”]},
“set-permission”: {“name”: “config-edit”, “role”:[“build”,”admin”]},
“set-permission”: {“name”: “core-admin-edit”, “role”:[“build”,”admin”]}
}’ http://localhost:8983/solr/admin/authorization

The final step is to confirm the security.json which will look like the following:


NOTE: You can always edit the permission, map roles to respective permissions based on indexes like the following:

curl — user admin:iamadmin -H ‘Content-type:application/json’ -d ‘{
“update-permission”: {“index”: 3,
“role”: [“admin”, “dev”]}
}’ http://localhost:8983/solr/admin/authorization

That’s it, the use-case is implemented and the respective access control to users is in place.

Moving forward in future releases the above-mentioned explanations and examples may no longer apply. Please leave your suggestions, improvements, and feedback in the comments. Cheers!

Lucene / Solr - Lucidworks Inc