{"authentication":{"class": "org.apache.solr.security.KerberosPlugin", "blockUnknown": true},"authorization":{"class":"solr.RuleBasedAuthorizationPlugin","permissions":[{"name":"security-edit","role":"admin"},{"name":"collection-admin-edit", "role" : "dev"},{"name":"read", "role" : "read_coll_data","path":"/select"}, {"name":"update", "role" : "put_coll_data"}],"user-role":{"a1@EXAMPLE.COM":"admin", "a2@EXAMPLE.COM":"dev", "a3@EXAMPLE.COM":"read_coll_data", "a4@EXAMPLE.COM":"put_coll_data", "a5@EXAMPLE.COM": "read_coll_data","rangeradmin@EXAMPLE.COM":["read_coll_data", "put_coll_data"]}}} This file has two parts, the authentication part and the authorization part. The authentication part stores information about the class being used for authentication. The authorization part is not related to Basic authentication, but is a separate authorization plugin designed to support fine-grained user access control. Each role is comprised of one or more permissions which define what the user is allowed to do. The permissions are consulted in order they appear in security.json file. The first permission that matches is applied for each user, so the strictest permissions should be at the top of the list. Permissions order can be controlled with a parameter of the Authorization API Roles are defined in json file: The 'admin' role has been defined, and it has permission to edit security settings. The 'dev' role has been defined, and it has permission to edit a collection's configuration using the collection API. The 'read_coll_data' role has been defined, and it has permission to perform any read action on any collection. The 'put_coll_data' role has been defined, and it has permission to perform any update action on any collection. Note: All requests w/o credentials will be rejected with a 401 error. Set 'blockUnknown' to false (or remove it altogether) if you wish to let unauthenticated requests to go through. However, if a particular resource is protected by a rule, they are rejected anyway with a 401 error. ... View more