Securing Solr With Basic Authentication
Examples and tutorial on the best ways to secure Solr with basic authentication.
Before 5.2, Apache Solr did not include any specific security features. If you wanted to secure your Solr installation, you needed to use external tools and solutions which were proprietary and maybe not so well known by your organization. A security API was introduced in Solr 5.2 and Solr 5.3 will have full-featured authentication and authorization plugins that use Basic authentication and „permission rules“ which are completely driven from ZooKeeper.
Caveats
- Basic authentication sends credentials in plain text. If the communication channels are not secure, attackers can know the password. You should still secure your communications with SSL.
- ZooKeeper is the weakest link in this security. Ensure that write permissions to ZooKeeper is granted only to appropriate users.
- It is still not safe to expose your Solr servers to an unprotected network.
Enabling Basic Authentication
Step 1 : Save the following JSON to a file called security.json
:
{ "authentication":{ "class":"solr.BasicAuthPlugin", "credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="} }, "authorization":{ "class":"solr.RuleBasedAuthorizationPlugin", "user-role":{"solr":"admin"}, "permissions":[{"name":"security-edit", "role":"admin"}] }}
The above configuration does the following:
- Enable authentication and authorization
- A user called
'solr'
is created with a password'SolrRocks'
- The user
'solr'
is assigned a role'admin'
- The permissions to edit security is now restricted to the role
'admin'
. All other resources are unprotected and the user should configure more rules to secure them. - This does not block any unauthenticated access to paths other than security-edit operations. However, it is possible to block all unauthenticated access by adding the attribute
blockUnknown=true
to the authentication section
Step 2: Upload to ZooKeeper
server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:9983 -cmd putfile /security.json security.json
All solr nodes watch the /security.json
and this change is immediately reflected in the nodes behavior. You can verify the operation with the following commands.
curl http://localhost:8983/solr/admin/authentication curl http://localhost:8983/solr/admin/authorization
These calls should return with the corresponding sections in the json we uploaded.
BasicAuthPlugin
The BasicAuthPlugin
authenticates users using HTTP’s Basic authentication mechanism. Authentication is done against the user name and salted sha256 hash of the password stored in ZooKeeper.
Editing credentials
There is an API to add, edit or remove users. Please note that the commands shown below are tied to this specific Basic authentication implementation and the same set of commands are not valid if the implementation class is not solr.BasicAuthPlugin
.
Example 1: Add a user and/or edit a password
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 'Content-type:application/json'-d '{ "set-user": {"tom" : "TomIsCool" , "harry":"HarrysSecret"}}'
Example 2: Delete a user
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 'Content-type:application/json'-d '{ "delete-user": ["tom","harry"]}'
Rule-Based Authorization Plugin
This plugin relies on the configuration stored in ZooKeeper to determine if a particular user is allowed to make a request. The configuration has two sections:
- A mapping of users to roles. A role can be any user defined string.
- A set of permissions and the rules on who can access what.
What Is a Permission?
A permission is a white-list roles that can access a resource. Most well-known resources have predefined names.
How Is a Permission Matched?
For an incoming request, the permissions are tested in the order in which they appear in the configuration. The first permission to match is applied. If you have multiple permissions that can match a given request, put the strictest permissions first. For example, if there is a generic permission that says anyone with a 'dev'
role can perform write operations to any collection and you wish to restrict write operations to .system
collection to admin only, add the permission for the latter before the more generic permission.
If there is no permission matching a given request, then it is accessible to all
Well Known Permissions
There are a few convenience permissions which are commonly used. They have fixed default values for certain attributes. If you use one of the following permissions just specify the roles who can access these. Trying to specify other attributes for the following will give an error.
- security-edit : Edit security configuration
- security-read : Read security configuration
- schema-edit : Edit schema of any collection
- schema-read : Read schema of any collection
- config-read : Read solrconfig of any collection
- config-edit : Edit config of any collection
- collection-admin-read : Read operations performed on
/admin/collections
such as LIST, CLUSTERSTATUS - collection-admin-edit : All operations on
/admin/collections
which can modify the state of the system - core-admin-read : Read operations on the core admin API
- core-admin-edit : Core admin commands that can mutate the system state
- update : Update operation on any collection
- read : Any read handler such as
/select
,/get
in any collection - all : Any request coming to Solr
User-defined permissions
It is possible to create a permission by specifying the attributes of a request and the roles that are allowed to make such a request. The attributes are all multivalued. The attributes of request are:
- collection: The name of the collection for which this rule should be applied to. If this value is not specified, it is applicable to all collections.
- path: This is the handler name for the request. It can support wild card prefixes as well.For example,
/update/*
will apply to all handlers under/update/
. - method: HTTP methods valid for this permission. Allowed values are
GET
,POST
,PUT
,DELETE
, andHEAD
. - params: These are the names and values of request parameters. For example,
"params":{"action":["LIST","CLUSTERSTATUS"]}
restricts the rule to be matched only when the values of the parameter"action"
is one of"LIST"
or"CLUSTERSTATUS"
.
Editing permissions
There is an API to edit the permissions. Please note that the following commands are valid only for the RulesBasedAuthorizationPlugin
.
The commands for managing permissions are:
set-permission
: create a new permission, overwrite an existing permission definition, or assign a pre-defined permission to a role.update-permission
: update some attributes of an existing permission definition.delete-permission
: remove a permission definition.
Example 1: Add or Remove Roles
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 'Content-type:application/json' -d '{ "set-user-role": {"tom":["admin","dev"}, "set-user-role": {"harry":null} }'
Example 2: Add a Well-Known Permission
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 'Content-type:application/json'-d '{ "set-permission": { "name":"update","role": "dev"} }'
Example 3: Add or Remove a User-Defined Permission
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 'Content-type:application/json'-d '{ "set-permission": { "name":"a-custom-permission-name", "collection":"gettingstarted", "path":"/handler-name" "role": "dev" }, "delete-permission":"permission-name" }'
Please note that the "set-permission"
replaces your permission fully. Use the "update-permission"
operation to partially update a permission. Use the 'before'
property to re-order your permissions
Example 4: Restrict Collection Admin Operations (Writes Only) to be Performed By an Admin Only
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 'Content-type:application/json' -d '{ "set-permission" : {"name":"collection-admin-edit", "role":"admin"}}'
This ensures that the write operations can be performed by admin only. Trying to perform a secure operation without credentials with a browser will now prompt for user-name and password:
Example 5: Restrict All writes to All Collections to Dev Role
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 'Content-type:application/json' -d '{ "set-permission" : {"name":"update", "role":"dev"}}'
Example 6 : Restrict Writes to .system
Collection to Admin Only
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 'Content-type:application/json' -d '{ "set-permission" : {"name":"system-coll-write", "collection": ".system" "path":"/update/*", "before":3, "role":"admin"}}'
Please note the 'before'
attribute, this ensures that this permission is inserted right before the permission at index 3.
Example 7 : Update the Above Permission to Add the /blob* Path
curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 'Content-type:application/json' -d '{ "update-permission" : {"name":"system-coll-write", "path": ["/update/*","/blob/*"]}}'
Securing Inter-node calls
BasicAuthPlugin uses Solr’s own mechanism for securing inter-node calls using PKI infrastructure. (That is topic for another blog)
LEARN MORE
Contact us today to learn how Lucidworks can help your team create powerful search and discovery applications for your customers and employees.