Hi Json,
Many thanks for this excellent explanation, it's all now clear to me, I've
fixed the problem!
I didn't anticipate that the aliases would be resolved before everything
else..
Thanks again!
Sotiri
On Tue, Jun 4, 2019 at 2:07 PM Jason Gerlowski <gerlowsk...@gmail.com>
wrote:
> Hi Sotiris,
>
> First off, forget what I said earlier about the "all" permission.
> What I said is mostly correct, but I had forgotten about some of the
> other behavior here that complicates things some.
>
> I replicated the behavior you're seeing and spent a bit of time
> tracing things through on the Solr side. I'll walk through it below
> in more detail, but ultimately what I think you're running into is
> that aliases are resolved _before_ authorization is done. The only
> way to write permissions affecting an alias is to write permissions
> that affect the underlying collections. The way I'm reading the authz
> code, a permission like {"collection": "sCollAlias", "path":
> "/select/*", "role": "readSCollAlias"} (taken from your first email),
> will never have any effect because Solr treats that incoming request
> as being for collection "sColl" (I'm just guessing at this name) by
> the point authz gets triggered.
>
> > Could someone please ELI5 going through the rules one by one?
>
> RBAP's process of authorizing requests is complicated, but it might
> help to think of it happening in 2 distinct steps:
>
> 1. Find the first rule (if any) that matches the incoming request. A
> rule matches if the "collection", "path", "method", and "params"
> properties all match values in the incoming request.
> 2. Looks at the "role" for the selected permission. Allow the request
> if the user making the request has this role. Otherwise deny the
> request.
>
> The second half of this process is pretty straightforward. The first
> half (determining which permission rule governs the request) is the
> complicated bit that causes most of the confusion. So in debugging
> RBAP, the real question is: how are permissions ordered, and how does
> Solr determine which one matches an incoming request?
>
> 1. First, Solr figures out which collections are involved in a
> request. Solr looks at the path param (e.g. /solr/foo/select), the
> "collection" query-param (e.g.
> /collections?action=CLUSTERSTATUS&collection=foo), and resolves any
> aliases (e.g. fooAlias -> fooCollection). It gets the collections
> referenced in all these places and puts them together in a list.
> 2. Solr begins looking for rules that match the incoming request. A
> permission is considered a match if the "collection", "path",
> "method", and "params" properties (when defined) all match values on
> the incoming request. security.json shows the permissions in a flat
> list, but this isn't the order they're tested in. Instead, the
> permissions are tested in the following order:
> 2a. Permissions with both "collection" and "path" present and matching
> the incoming request
> 2b. Permissions with "collection" matching, but no path specified
> 2c. Permissions with no "collection" specified (or the wildcard values
> specified) and a "path" matching the incoming request
> 2d. Permissions agnostic of both "collection" and "path"
> 3. Within each of the sub-steps above, permissions are tested in the
> order they appear in security.json.
> 4. When testing each individual permission, Solr either looks at the
> remaining properties ("method", "params"). If those check out, we've
> got a winner. This is the only permission that will matter for this
> request.
>
> So that's the logic in how the rules are processed. Let's walk
> through your originally posted security.json and see how this works
> out in practice for a request from "user". I'm assuming that
> sCollAlias is an alias that references the single collection "Coll".
> Imagine a request from "user" for
> http://<host>:8983/solr/sCollAlias/select?q=*:*
>
> 1. Solr looks at the request and realizes that sCollAlias really
> points to Coll. It puts "Coll" in its list of referenced-collections.
> 2. Solr looks for permissions with a "collection" value of "Coll" and
> a path value of "/select". There is one: {name:readColl,
> collection:Coll, path:/select, role:readColl}
> 3. Looking at that permission further, Solr makes sure the "method"
> and "params" properties match the request. Since the properties
> aren't present, they're treated as wildcards and implicitly match.
> 4. So we've found a matching permission, now Solr checks whether
> "user" has the correct role. The permission says that this request
> can only be made by those with the role "readColl". But "user" only
> has the role "readSCollAlias". So the request is denied.
>
> Hope that example helps. Let me know if you have any more questions.
>
> Best,
>
> Jason
>
> On Mon, Jun 3, 2019 at 2:06 PM Sotiris Fragkiskos <sfra...@gmail.com>
> wrote:
> >
> > it's 7.2.1. Thanks!
> >
> > On Mon, Jun 3, 2019 at 6:26 PM Jason Gerlowski <gerlowsk...@gmail.com>
> > wrote:
> >
> > > Hi Sotiris,
> > >
> > > What version of Solr are you running? The behavior has changed some
> > > over time, both intentionally and due to bugs that have come and gone
> > > over time. I (or someone else) can explain things and offer you
> > > better help once we know your Solr version.
> > >
> > > Jason
> > >
> > > On Mon, Jun 3, 2019 at 12:13 PM Sotiris Fragkiskos <sfra...@gmail.com>
> > > wrote:
> > > >
> > > > Hi again,
> > > >
> > > > I moved the "all" permission to the bottom as suggested, but it still
> > > > doesn't work. Actually, i tried all possible combinations that I
> could
> > > > think of, but I just can't get it to work.
> > > > Could there be something else that I'm doing wrong? I'm a complete
> > > newbie,
> > > > so pretty much anything is a possibility at this point :(
> > > > Could it be because I use getfile/putfile commands to update the
> > > > security.json file? (it seems to be working, i.e. what i put with
> putfile
> > > > is later retrieved successfully with getfile)
> > > > Could there be some system update/refresh mechanism that I'm not
> aware of
> > > > and is currently not taking place?
> > > > Could someone please ELI5 going through the rules one by one? I can't
> > > > exactly understand the "narrative" that's going on,
> > > >
> > > > My security.json file's "authorization" at this point looks like the
> > > > snippet below, and almost nothing is working (except admin, and userC
> > > who,
> > > > for some weird reason, can access readCollC55b , which is tied to a
> role
> > > > that the userC is NOT tied to..
> > > > I'm completely lost.... any pointers, anyone?
> > > > Mind you, i'm testing whether it works either directly in the
> browser by
> > > > prepending a "username:password@" to the URL or from the cmdline
> with a
> > > > curl command like so:
> > > > *curl http://<user:pass>@IP/solr/collName/select?q=field:value*
> > > >
> > > > Many thanks!
> > > > Sotiri
> > > >
> > > > "authorization":{
> > > > "class":"solr.RuleBasedAuthorizationPlugin",
> > > > "permissions":[
> > > > {
> > > > "name":"readCollA",
> > > > "collection":"CollA",
> > > > "path":"/select/*",
> > > > "role":"readCollA",
> > > > "index":1},
> > > > {
> > > > "name":"readCollB",
> > > > "collection":"CollB",
> > > > "path":"/select/*",
> > > > "role":"readCollB",
> > > > "index":2},
> > > > {
> > > > "name":"readCollC55b",
> > > > "collection":"CollC55b",
> > > > "path":"/select/*",
> > > > "role":"readCollC55b",
> > > > "index":3},
> > > > {
> > > > "name":"readCollCProduction",
> > > > "collection":"CollCProd",
> > > > "path":"/select/*",
> > > > "role":"readCollCProduction",
> > > > "index":4},
> > > > {
> > > > "name":"all",
> > > > "role":"admin",
> > > > "index":5}],
> > > > "user-role":{
> > > > "admin":[
> > > > "admin",
> > > > "readCollB",
> > > > "readCollA",
> > > > "readCollC55b",
> > > > "readCollCProduction"],
> > > > "userA":["readCollC55b"],
> > > > "userB":["readCollC55b"],
> > > > "userC":["readCollCProduction"],
> > > > "userD":[
> > > > "readCollCProduction",
> > > > "readCollC55b",
> > > > "readCollB",
> > > > "readCollA"]},
> > > >
> > > >
> > > >
> > > > On Fri, May 31, 2019 at 9:07 PM Sotiris Fragkiskos <
> sfra...@gmail.com>
> > > > wrote:
> > > >
> > > > > Terribly sorry about the duplicate post. It was just when i had
> first
> > > > > subscribed, i mustn't have verified my subscription because i never
> > > > > received any posts. I could also not find my post in the mailing
> list
> > > > > archive, so I thought it never arrived. It was only today that I
> tried
> > > > > subscribing again (+verifying) that I started receiving emails.
> > > > > Thanks for your explanation, I had read this in the manual but it
> > > didn't
> > > > > make much sense to me. I intepreted my order as: "first rule, the
> > > request
> > > > > is not from an admin so fail, check the next rule, it's from role
> > > readColl
> > > > > trying to access Coll, go ahead"
> > > > > I will try it as soon as I can. Thanks very much.
> > > > > I'm currently using 7.2.
> > > > >
> > > > > On Fri, May 31, 2019 at 8:27 PM Jason Gerlowski <
> gerlowsk...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> Hi Sotiris,
> > > > >>
> > > > >> Is this your second time asking this question here, or is there a
> > > > >> subtle difference I'm missing? You asked a very similar question
> a
> > > > >> week or so ago, and I replied with a few suggestions for changing
> your
> > > > >> security.json and with a few questions. In case you missed it for
> > > > >> whatever reason, I'll include my original response below:
> > > > >>
> > > > >> -----
> > > > >>
> > > > >> Hi Sotiris,
> > > > >>
> > > > >> First, what version of Solr are you running? We've made some
> fixes
> > > > >> recently (esp. SOLR-13355) to RBAP, and they might affect the
> behavior
> > > > >> you're seeing or any fixes we can recommend.
> > > > >>
> > > > >> Second, the order of permissions in security.json has a huge
> effect on
> > > > >> how . Solr always uses the first permission rule that matches a
> given
> > > > >> API...later rules are ignored if a match is found in earlier ones.
> > > > >> The first rule in your permissions block ({"name": "all", "role":
> > > > >> "admin"}) will match all APIs and will only allow requests
> through if
> > > > >> the requesting user has the "admin" role. So "user" being unable
> to
> > > > >> query an alias makes sense. Usually "all" and other catchall
> > > > >> permissions are best used at the very bottom of your permissions
> list.
> > > > >> That way the catchall is the last rule to be checked, giving other
> > > > >> rules a chance to match first.
> > > > >>
> > > > >> Hope that helps.
> > > > >>
> > > > >> On Fri, May 31, 2019 at 9:34 AM Sotiris Fragkiskos <
> sfra...@gmail.com
> > > >
> > > > >> wrote:
> > > > >> >
> > > > >> > Hi everyone!
> > > > >> > I've been trying unsuccessfully to read an alias to a collection
> > > with a
> > > > >> > curl command.
> > > > >> > The command only works when I put in the admin credentials,
> > > although the
> > > > >> > user I want access for also has the required role for accessing.
> > > > >> > Is this perhaps built-in, or should anyone be able to access an
> > > alias
> > > > >> from
> > > > >> > the API?
> > > > >> >
> > > > >> > The command I'm using is:
> > > > >> > curl http://<user>:<pass>@<solrhostname>/solr
> > > > >> > /<AliasName>/select?q=<field>:<value>
> > > > >> > This fails for the user but succeeds for the admin
> > > > >> >
> > > > >> > My minimum working example of security.json follows.
> > > > >> > Many thanks!
> > > > >> >
> > > > >> > {
> > > > >> > "authentication":{
> > > > >> > "blockUnknown":true,
> > > > >> > "class":"solr.BasicAuthPlugin",
> > > > >> > "credentials":{
> > > > >> > "admin":"blahblahblah",
> > > > >> > "user":"blahblah"},
> > > > >> > "":{"v":13}},
> > > > >> > "authorization":{
> > > > >> > "class":"solr.RuleBasedAuthorizationPlugin",
> > > > >> > "permissions":[
> > > > >> > {
> > > > >> > "name":"all",
> > > > >> > "role":"admin",
> > > > >> > "index":1},
> > > > >> > {
> > > > >> > "name":"readColl",
> > > > >> > "collection":"Coll",
> > > > >> > "path":"/select/*",
> > > > >> > "role":"readColl",
> > > > >> > "index":2},
> > > > >> > {
> > > > >> > "name":"readSCollAlias",
> > > > >> > "collection":"sCollAlias",
> > > > >> > "path":"/select/*",
> > > > >> > "role":"readSCollAlias",
> > > > >> > "index":3}],
> > > > >> > "user-role":{
> > > > >> > "admin":[
> > > > >> > "admin",
> > > > >> > "readSCollAlias"],
> > > > >> > "user":["readSCollAlias"]},
> > > > >> > "":{"v":21}}}
> > > > >>
> > > > >
> > >
>
