11.05.2016 Views

Apache Solr Reference Guide Covering Apache Solr 6.0

21SiXmO

21SiXmO

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

to support fine-grained user access control. When creating security.json you can add the permissions to the<br />

file, or you can use the Authorization API described below to add them as needed.<br />

This example security.json shows how the Basic authentication plugin can work with this authorization<br />

plugin:<br />

{<br />

"authentication":{<br />

"class":"solr.BasicAuthPlugin",<br />

"blockUnknown": true,<br />

"credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=<br />

Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}<br />

},<br />

"authorization":{<br />

"class":"solr.RuleBasedAuthorizationPlugin",<br />

"permissions":[{"name":"security-edit",<br />

"role":"admin"}]<br />

"user-role":{"solr":"admin"}<br />

}}<br />

There are several things defined in this example:<br />

Basic authentication and rule-based authorization plugins are enabled.<br />

A user called 'solr', with a password has been defined.<br />

All requests w/o credentials will be rejected with a 401 error. Set 'blockUnknown' to false (or remove it<br />

altogether) if you wish to let unauthenticated requests to go through. However, if a particular resource is<br />

protected by a rule, they are rejected anyway with a 401 error.<br />

The 'admin' role has been defined, and it has permission to edit security settings.<br />

The 'solr' user has been defined to the 'admin' role.<br />

Permission Attributes<br />

Each role is comprised of one or more permissions which define what the user is allowed to do. Each permission<br />

is made up of several attributes that define the allowed activity. There are some pre-defined permissions which<br />

cannot be modified.<br />

The permissions are consulted in order they appear in security.json. The first permission that matches is<br />

applied for each user, so the strictest permissions should be at the top of the list. Permissions order can be<br />

controlled with a parameter of the Authorization API, as described below.<br />

Pre-defined Permissions<br />

There are several permissions that are pre-defined. These have fixed default values, which cannot be modified,<br />

and new attributes cannot be added. To use these attributes, simply define a role that includes this permission,<br />

and then assign a user to that role.<br />

The pre-defined permissions are:<br />

security-edit: this permission is allowed to edit the security configuration, meaning any update action that<br />

modifies security.json through the APIs will be allowed.<br />

security-read: this permission is allowed to read the security configuration, meaning any action that reads<br />

security.json settings through the APIs will be allowed.<br />

schema-edit: this permission is allowed to edit a collection's schema using the Schema API. Note that<br />

this allows schema edit permissions for all collections. If edit permissions should only be applied to<br />

specific collections, a custom permission would need to be created.<br />

schema-read: this permission is allowed to read a collection's schema using the Schema API. Note that<br />

this allows schema read permissions for all collections. If read permissions should only be applied to<br />

specific collections, a custom permission would need to be created.<br />

config-edit: this permission is allowed to edit a collection's configuration using the Config API, the Reque<br />

<strong>Apache</strong> <strong>Solr</strong> <strong>Reference</strong> <strong>Guide</strong> <strong>6.0</strong><br />

522

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!