Re: Authentication for all but selects
Thanks Craig!
I got the following to work.
{
"authentication":{
"blockUnknown":false,
"class":"solr.BasicAuthPlugin",
"credentials":{"solr":"..."}},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"user-role":{"solr":"admin"},
"permissions":[
{
"name":"all",
"role":"admin",
"index":1},
{
"name":"open_select",
"collection":"*",
"path":"/select",
"role":null,
"index":2}],
"":{"v":0}}}
On 2/5/21, 3:35 PM, "Oakley, Craig (NIH/NLM/NCBI) [C]"
wrote:
What works for us is having something like this at the bottom of
security.json:
{
"name":"open_select",
"path":"/select/*",
"role":null,
"index":9},
{
"name":"catch-all-nocollection",
"collection":null,
"path":"/*",
"role":"allgen",
"index":10},
{
"name":"catch-all-collection",
"path":"/*",
"role":"allgen",
"index":11}],
"":{"v":9}}}
The clause with the name open_select specifically allows selects to run
without any role ("role":null)
The last two clauses say that anything else (with any collection and
without any collection) requires allgen role: and that is a role that I grant
to all users generally
Other permissions can go higher up in security.json (disallowing normal
users from running DELETEREPLICA, and things like that); but these are the
three clauses which I think should allow select without any login (and without
any password), while everything else does require a login and password.
-Original Message-
From: Robert Douglas
Sent: Friday, February 05, 2021 1:19 PM
To: solr-user@lucene.apache.org
Subject: Authentication for all but selects
Hello all,
We are working on some migrations and we want to be incorporating
authentication more uniformly across all our installations of Solr, but we are
getting stuck on allowing Select statements through without authentication
while having authentication on with RBAP for everything else. For some of our
apps the authentication for Selects isn’t an issue but for others, where we
can’t really touch the code, it is.
Is there a way of doing this?
Cheers,
R
Robert Douglas
DevOps Engineer
Cornell University Library
RE: Authentication for all but selects
What works for us is having something like this at the bottom of security.json:
{
"name":"open_select",
"path":"/select/*",
"role":null,
"index":9},
{
"name":"catch-all-nocollection",
"collection":null,
"path":"/*",
"role":"allgen",
"index":10},
{
"name":"catch-all-collection",
"path":"/*",
"role":"allgen",
"index":11}],
"":{"v":9}}}
The clause with the name open_select specifically allows selects to run without
any role ("role":null)
The last two clauses say that anything else (with any collection and without
any collection) requires allgen role: and that is a role that I grant to all
users generally
Other permissions can go higher up in security.json (disallowing normal users
from running DELETEREPLICA, and things like that); but these are the three
clauses which I think should allow select without any login (and without any
password), while everything else does require a login and password.
-Original Message-
From: Robert Douglas
Sent: Friday, February 05, 2021 1:19 PM
To: solr-user@lucene.apache.org
Subject: Authentication for all but selects
Hello all,
We are working on some migrations and we want to be incorporating
authentication more uniformly across all our installations of Solr, but we are
getting stuck on allowing Select statements through without authentication
while having authentication on with RBAP for everything else. For some of our
apps the authentication for Selects isn’t an issue but for others, where we
can’t really touch the code, it is.
Is there a way of doing this?
Cheers,
R
Robert Douglas
DevOps Engineer
Cornell University Library
Authentication for all but selects
Hello all, We are working on some migrations and we want to be incorporating authentication more uniformly across all our installations of Solr, but we are getting stuck on allowing Select statements through without authentication while having authentication on with RBAP for everything else. For some of our apps the authentication for Selects isn’t an issue but for others, where we can’t really touch the code, it is. Is there a way of doing this? Cheers, R Robert Douglas DevOps Engineer Cornell University Library
