lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Gerlowski <gerlowsk...@gmail.com>
Subject Re: Solr RuleBasedAuthorizationPlugin question
Date Tue, 07 May 2019 16:08:13 GMT
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 <merejy@gmail.com> 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 <gerlowskija@gmail.com>
> 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 <merejy@gmail.com> 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
> >

Mime
View raw message