The Admin UI lockdown is a known-issue in RBAP that's since been
fixed. (https://issues.apache.org/jira/browse/SOLR-13344), but only in
very recent versions of Solr. I haven't tried this, but you should be
able to work around it by putting a rule like: {path: /, role: *}
right before your catch-all rule. (I think "/" is the path that RBAP
sees for Admin UI requests. Though you may also want to try
"/solr/").
As for why core-creation is still allowed with that config, I'll try
to take a quick look after work today, but may not have time to get to
it. It's a bit of a hack, and it'd be nice to understand the behavior
now before making additional changes, but if you need to you can add
an explicit rule to cover core creation:
{
"name": "core-admin-edit",
"role": "admin"
},
{
"name": "read",
"role": "readonly"
},
{
"path": "*",
"role": "admin"
},
{
"name": "*",
"role": "admin"
}
Good luck,
Jason
On Tue, May 7, 2019 at 11:31 AM Jérémy <[email protected]> wrote:
>
> Hi Jason,
>
> Thanks a lot for the detailed explanation. It's still very unclear in my
> head how things work, but now I know about the weird fallback mechanism of
> RBAP. Despite your example I still didn't manage to get the behavior I
> wanted.
> Here's the closest I've been so far. Any logged in user can still create
> cores but now the readonly user cannot delete or update documents. However
> the admin UI webinterface is completely locked now.
>
> {
> "authentication": {
> "blockUnknown": true,
> "class": "solr.BasicAuthPlugin",
> "credentials": {
> "adminuser": "adminpwd",
> "readuser": "readpwd"
> }
> },
> "authorization": {
> "class": "solr.RuleBasedAuthorizationPlugin",
> "permissions": [
> {
> "name": "read",
> "role": "readonly"
> },
> {
> "path": "*",
> "role": "admin"
> },
> {
> "name": "*",
> "role": "admin"
> }
> ],
> "user-role": {
> "readuser": "readonly",
> "adminuser": ["admin", "readonly"]
> }
> }
> }
>
> I feel like I'm almost there and that the json is just missing a bit.
>
> Thanks for your help, I really appreciate it,
> Jeremy
>
>
>
>
> On Mon, May 6, 2019 at 11:00 PM Jason Gerlowski <[email protected]>
> wrote:
>
> > Hey Jeremy,
> >
> > One important thing to remember about the RuleBasedAuthorizationPlugin
> > is that if it doesn't find any rules matching a particular API call,
> > it will allow the request. I think that's what you're running into
> > here. Let's trace through how RBAP will process your rules:
> >
> > 1. Solr receives an API call. For this example, let's say its a new
> > doc sent to /solr/someCollection/update
> > 2. Solr fetches security.json and parses the auth rules. It'll look
> > at each of these in turn.
> > 3. First Rule: Solr checks "/solr/someCollection/update" against the
> > "read" rule. /update isn't a read API, so this rule doesn't apply to
> > our request.
> > 4. Second Rule: Solr checks "/solr/someCollection/update" agains the
> > "security-edit" rule. /update isn't a security-related API, so this
> > rule doesn't apply to our request either.
> > 5. Solr is out of rules to try. Since no rules locked down /update to
> > a particular user/role, Solr allows the request.
> >
> > This is pretty unintuitive and rarely is what people expect. The way
> > that RBAP works, you almost always will want to have the last rule in
> > your security.json be a "catch-all" rule of some sort. You can do
> > this by appending a rule entry with the wildcard path "*". In the
> > latest Solr releases, you can also use the predefined "all" permission
> > (but beware of SOLR-13355 in earlier version). e.g.
> >
> > {
> > "name": "read",
> > "role": "readonly"
> > },
> > {
> > "name": "security-edit",
> > "role": "admin"
> > },
> > {
> > "path": "*",
> > "role": "admin"
> > }
> >
> >
> > Hope that helps.
> >
> > Jason
> >
> > On Fri, May 3, 2019 at 5:23 PM Jérémy <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > I hope that this question wasn't answered already, but I couldn't find
> > what
> > > I was looking for in the archives.
> > >
> > > I'm having a hard time to use solr with the BasicAuth and
> > > RoleBasedAuthorization plugins.
> > > The auth part works well but I have issues with the
> > RoleBasedAuthorization
> > > part. I'd like to have an admin role and a readonly one. I have two
> > users,
> > > each having one role. However both of them can create cores, delete
> > > documents etc...
> > >
> > > Here's my security.json:
> > > {
> > > "authentication": {
> > > "blockUnknown": true,
> > > "class": "solr.BasicAuthPlugin",
> > > "credentials": {
> > > "adminuser": "adminpwd",
> > > "readuser": "readpwd"
> > > }
> > > },
> > > "authorization": {
> > > "class": "solr.RuleBasedAuthorizationPlugin",
> > > "permissions": [
> > > {
> > > "name": "read",
> > > "role": "readonly"
> > > },
> > > {
> > > "name": "security-edit",
> > > "role": "admin"
> > > }
> > > ],
> > > "user-role": {
> > > "readuser": "readonly",
> > > "adminuser": "admin"
> > > }
> > > }
> > > }
> > >
> > > I tried that with Solr 7.7.0 and 8.0.0, in cloud and standalone mode. I
> > > can't figure out why the readuser can delete documents.
> > >
> > > Any help is appreciated!
> > >
> > > Thanks,
> > > Jeremy
> >
