You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Jérémy <me...@gmail.com> on 2019/05/03 21:22:46 UTC
Solr RuleBasedAuthorizationPlugin question
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
Re: Solr RuleBasedAuthorizationPlugin question
Posted by Jérémy <me...@gmail.com>.
Hi Jason,
Thanks for the your help again.
Your suggestion for the core creation works well. I tried both workarounds
for the admin UI but without any success. No worries I'll watch the issue
and wait for its resolution.
Thank you!
Jeremy
On Tue, May 7, 2019 at 6:08 PM Jason Gerlowski <ge...@gmail.com>
wrote:
> 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 <me...@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 <ge...@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 <me...@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
> > >
>
Re: Solr RuleBasedAuthorizationPlugin question
Posted by Jason Gerlowski <ge...@gmail.com>.
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 <me...@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 <ge...@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 <me...@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
> >
Re: Solr RuleBasedAuthorizationPlugin question
Posted by Jérémy <me...@gmail.com>.
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 <ge...@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 <me...@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
>
Re: Solr RuleBasedAuthorizationPlugin question
Posted by Jason Gerlowski <ge...@gmail.com>.
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 <me...@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