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 Terry Steichen <te...@net-frame.com> on 2018/03/12 22:07:48 UTC
Resend: Authorization on 6.6.0
I'm resending the information below because the original message got the
security.json stuff garbled.
--------------------------------------------------------------------------------
I'm using 6.6.0 with security.json active, having the content shown
below. I am running standalone mode, have two solr cores defined:
email1, and email2. Since the 'blockUnknown' is set to false, everyone
should have access to any unprotected resource. As you can see, I have
three users defined: joe, solr and terry (the latter two having an admin
role).
What I expect to happen is for user joe (who is not an admin) to be able
to access core emails2 without being challenged for his credentials.
But, user joe should also be challenged and not allowed to access emails1.
But solr appears to ignore the "collections" portion of the permission -
it denies joe access to both cores.
Is this a bug (in that auth doesn't work properly in 6.6.0 standalone),
or am I (once again) missing something?
Terry
{
"authentication": {
"class": "solr.BasicAuthPlugin",
"blockUnknown": true,
"credentials": {
"solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=",
"joe": "iGx0BaTgmjmCxrRmaD3IsCb2MJ21x1vqhfdzbwyu9MY=
P+aA0Bx811jzRwR97bOn/x/jyvpoKiHpWIRRXGAc8tg=",
"terry": "q71fVfo/DIeCSfc1zw6YMyXVjU24Jr2oLniEkXFdPe0=
oSaEbu/0TCg8UehLQ9zfoH3AvrJBqCaIoJkt547WIrc="
},
"": {
"v": 0
}
},
"authorization": {
"class": "solr.RuleBasedAuthorizationPlugin",
"user-role": {
"solr": "admin",
"terry": "admin"
},
"permissions": [
{
"path": "/select",
"role": "admin"
}
]
}
}
Re: Continuing Saga of Authorization on 6.6.0
Posted by Chris Ulicny <cu...@iq.media>.
You can see the security.json file in the admin console if you go to the
Cloud tab, and then select Tree. It should be visible there without having
to navigate directly into zookeeper.
Best,
Chris
On Tue, Mar 13, 2018 at 1:26 PM Terry Steichen <te...@net-frame.com> wrote:
> Chris, many, many thanks. From a quick check, those changes seem to
> work. I think I'm getting too old to differentiate between brackets and
> curly braces. I'll get back on track and see if I can (finally) set
> this up right.
>
> What also puzzles me is that I can't find any "security.json" file.
> Clearly, solr is persistently keeping track of the
> authentication/authorization information, but I don't see where. I
> suppose it might be kept in zookeeper (which perhaps survives solr
> restarts - but I don't know). Any insights on that?
>
> Terry
>
> On 03/13/2018 01:01 PM, Chris Ulicny wrote:
> >> *failed to delete a user:*
> > "delete-user" is expecting an array of users in the json, so the data
> > should be: {"delete-user": ["lanny"]}
> >
> >
> >> *failed to set a permission: *
> > There are separate endpoints for authorization and authentication. You
> > should use ".../solr/admin/authorization" for the permissions instead of
> > "../solr/admin/authentication"
> >
> https://lucene.apache.org/solr/guide/7_2/rule-based-authorization-plugin.html#manage-permissions
> >
> > Disclaimer: I've never worked with 6.6, but I've not noticed any big
> > differences between the security for our 6.3 deployments and the 7.X
> ones.
> >
> > Best,
> > Chris
> >
> > On Tue, Mar 13, 2018 at 12:47 PM Terry Steichen <te...@net-frame.com>
> wrote:
> >
> >> I switched solr from standalone to cloud and created the two collections
> >> (emails1 and emails2).
> >>
> >> I was able to create a basic set of credentials via the curl-based
> >> API's. I could create users, and toggle the blockUnknown property
> >> status. However, the system refused to allow me to delete a user, or to
> >> set a permission.
> >>
> >> Here are the curl commands (with *terry:admin* as admin credentials) and
> >> results:
> >>
> >> *succeeded in setting blockUnknown property (verified by
> >> admin/authentication dump):*
> >>
> >> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{
> >> "set-property": {"blockUnknown" : true}}'
> >>
> >> *succeeded in adding a user (verified by admin/authentication dump):*
> >>
> >> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{
> >>> "set-user": {"lanny" : "hawaii"}}'
> >> *succeeded in changing lanny's password (verified by
> >> admin/authentication dump):*
> >>
> >> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{
> >> "set-user": {"lanny" : "hawaii_five_o"}}'
> >>
> >> *failed to delete a user:*
> >>
> >> curl --user terry:admin
> http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{
> >> "delete-user": {"lanny"}}'
> >> {
> >> "responseHeader":{
> >> "status":500,
> >> "QTime":1},
> >>
> >> "error":{ "msg":"Expected key,value separator ':': char=},position=26
> >> BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
> >> [terry here: plus a very long stack trace}
> >>
> >> *failed to set a permission: *
> >>
> >> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> >> -H <http://localhost:8983/solr/admin/authentication-H>
> >> 'Content-type:application/json' -d '{"set-permission" :
> >> {"name":"collection-admin-edit", "role":"admin"}}'
> >> {
> >> "responseHeader":{
> >> "status":0,
> >> "QTime":2},
> >> "errorMessages":[{
> >> "set-permission":{
> >> "name":"collection-admin-edit",
> >> "role":"admin"},
> >> "errorMessages":["Unknown operation 'set-permission' "]}]}
> >>
> >>
> >> This really makes no sense at all (or, I'm really losing it - always a
> >> distinct possibility). It's almost as if half of the documented
> >> parameters must have been changed, though I can't find any references to
> >> any such changes.
> >>
> >> I confess I'm about to just give up and find some other route to go.
> >>
> >> Terry
> >>
> >>
> >> On 03/12/2018 11:15 PM, Shawn Heisey wrote:
> >>> On 3/12/2018 8:39 PM, Terry Steichen wrote:
> >>>> I'm increasingly of the view that Solr's authentication/authorization
> >>>> mechanism doesn't work correctly in a _standalone_ mode. It was
> present
> >>>> in the cloud mode for quite a few versions back, but as of 6.0.0 (or
> so)
> >>>> it was supposed to be available in standalone mode too. It seems to
> >>>> partly work (when using the built-in permissions), but does not seem
> to
> >>>> work with customized, core-specific permissions.
> >>> I suspected based on your last message that the authorization feature
> >>> might only work correctly in SolrCloud. The entire authentication
> >>> feature was designed for SolrCloud. Version 6.5 brought the
> >>> security.json file to standalone mode. This was LONG after the
> >>> feature was introduced in 5.2 and had a LOT of bugs fixed in the three
> >>> 5.3.x releases.
> >>>
> >>> I just found the section in the documentation confirming what I
> >>> suspected.
> >>>
> >>>
> >>
> https://lucene.apache.org/solr/guide/7_2/authentication-and-authorization-plugins.html#authorization
> >>>
> >>> There is a note here that says "The authorization plugin is only
> >>> supported in SolrCloud mode. Also, reloading the plugin isn’t yet
> >>> supported and requires a restart of the Solr installation (meaning,
> >>> the JVM should be restarted, not simply a core reload)." The 6.6
> >>> documentation contains the same note that you can see here in the
> >>> latest docs.
> >>>
> >>> I have no idea how hard it would be to extend the authorization plugin
> >>> to support standalone cores as well as collections. I imagine that if
> >>> it were easy, it would have been done already.
> >>>
> >>> Thanks,
> >>> Shawn
> >>>
> >>>
> >>
>
>
Re: Continuing Saga of Authorization on 6.6.0
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/13/2018 12:00 PM, Terry Steichen wrote:
> So, Shawn, every time zookeeper gets shut down (intentionally or
> otherwise), I have to recreate the credentials and permissions via a set
> of API calls? Is there some way to have it save and read that stuff
> from disk?
If your ZK ensemble doesn't keep that info around through restarts, then
it is badly configured. The ZK database should be persistent. They do
have a concept of an ephemeral node, and I think Solr does use that
feature, but it should NOT be in use for the majority of what Solr puts
in ZK.
Thanks,
Shawn
Re: Continuing Saga of Authorization on 6.6.0
Posted by Terry Steichen <te...@net-frame.com>.
So, Shawn, every time zookeeper gets shut down (intentionally or
otherwise), I have to recreate the credentials and permissions via a set
of API calls? Is there some way to have it save and read that stuff
from disk?
Terry
On 03/13/2018 01:51 PM, Shawn Heisey wrote:
> On 3/13/2018 11:25 AM, Terry Steichen wrote:
>> What also puzzles me is that I can't find any "security.json" file.
>> Clearly, solr is persistently keeping track of the
>> authentication/authorization information, but I don't see where. I
>> suppose it might be kept in zookeeper (which perhaps survives solr
>> restarts - but I don't know). Any insights on that?
> Yes, with SolrCloud, the security.json file is kept in zookeeeper.
> Almost all of the configuration for SolrCloud is in zookeeper, so it can
> affect any server in the cloud. The only usual exception is solr.xml,
> and even that file CAN be in zookeeper.
>
> Thanks,
> Shawn
>
>
Re: Continuing Saga of Authorization on 6.6.0
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/13/2018 11:25 AM, Terry Steichen wrote:
> What also puzzles me is that I can't find any "security.json" file.
> Clearly, solr is persistently keeping track of the
> authentication/authorization information, but I don't see where. I
> suppose it might be kept in zookeeper (which perhaps survives solr
> restarts - but I don't know). Any insights on that?
Yes, with SolrCloud, the security.json file is kept in zookeeeper.
Almost all of the configuration for SolrCloud is in zookeeper, so it can
affect any server in the cloud. The only usual exception is solr.xml,
and even that file CAN be in zookeeper.
Thanks,
Shawn
Re: Continuing Saga of Authorization on 6.6.0
Posted by Terry Steichen <te...@net-frame.com>.
Chris, many, many thanks. From a quick check, those changes seem to
work. I think I'm getting too old to differentiate between brackets and
curly braces. I'll get back on track and see if I can (finally) set
this up right.
What also puzzles me is that I can't find any "security.json" file.
Clearly, solr is persistently keeping track of the
authentication/authorization information, but I don't see where. I
suppose it might be kept in zookeeper (which perhaps survives solr
restarts - but I don't know). Any insights on that?
Terry
On 03/13/2018 01:01 PM, Chris Ulicny wrote:
>> *failed to delete a user:*
> "delete-user" is expecting an array of users in the json, so the data
> should be: {"delete-user": ["lanny"]}
>
>
>> *failed to set a permission: *
> There are separate endpoints for authorization and authentication. You
> should use ".../solr/admin/authorization" for the permissions instead of
> "../solr/admin/authentication"
> https://lucene.apache.org/solr/guide/7_2/rule-based-authorization-plugin.html#manage-permissions
>
> Disclaimer: I've never worked with 6.6, but I've not noticed any big
> differences between the security for our 6.3 deployments and the 7.X ones.
>
> Best,
> Chris
>
> On Tue, Mar 13, 2018 at 12:47 PM Terry Steichen <te...@net-frame.com> wrote:
>
>> I switched solr from standalone to cloud and created the two collections
>> (emails1 and emails2).
>>
>> I was able to create a basic set of credentials via the curl-based
>> API's. I could create users, and toggle the blockUnknown property
>> status. However, the system refused to allow me to delete a user, or to
>> set a permission.
>>
>> Here are the curl commands (with *terry:admin* as admin credentials) and
>> results:
>>
>> *succeeded in setting blockUnknown property (verified by
>> admin/authentication dump):*
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{
>> "set-property": {"blockUnknown" : true}}'
>>
>> *succeeded in adding a user (verified by admin/authentication dump):*
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{
>>> "set-user": {"lanny" : "hawaii"}}'
>> *succeeded in changing lanny's password (verified by
>> admin/authentication dump):*
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{
>> "set-user": {"lanny" : "hawaii_five_o"}}'
>>
>> *failed to delete a user:*
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{
>> "delete-user": {"lanny"}}'
>> {
>> "responseHeader":{
>> "status":500,
>> "QTime":1},
>>
>> "error":{ "msg":"Expected key,value separator ':': char=},position=26
>> BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
>> [terry here: plus a very long stack trace}
>>
>> *failed to set a permission: *
>>
>> curl --user terry:admin http://localhost:8983/solr/admin/authentication
>> -H <http://localhost:8983/solr/admin/authentication-H>
>> 'Content-type:application/json' -d '{"set-permission" :
>> {"name":"collection-admin-edit", "role":"admin"}}'
>> {
>> "responseHeader":{
>> "status":0,
>> "QTime":2},
>> "errorMessages":[{
>> "set-permission":{
>> "name":"collection-admin-edit",
>> "role":"admin"},
>> "errorMessages":["Unknown operation 'set-permission' "]}]}
>>
>>
>> This really makes no sense at all (or, I'm really losing it - always a
>> distinct possibility). It's almost as if half of the documented
>> parameters must have been changed, though I can't find any references to
>> any such changes.
>>
>> I confess I'm about to just give up and find some other route to go.
>>
>> Terry
>>
>>
>> On 03/12/2018 11:15 PM, Shawn Heisey wrote:
>>> On 3/12/2018 8:39 PM, Terry Steichen wrote:
>>>> I'm increasingly of the view that Solr's authentication/authorization
>>>> mechanism doesn't work correctly in a _standalone_ mode. It was present
>>>> in the cloud mode for quite a few versions back, but as of 6.0.0 (or so)
>>>> it was supposed to be available in standalone mode too. It seems to
>>>> partly work (when using the built-in permissions), but does not seem to
>>>> work with customized, core-specific permissions.
>>> I suspected based on your last message that the authorization feature
>>> might only work correctly in SolrCloud. The entire authentication
>>> feature was designed for SolrCloud. Version 6.5 brought the
>>> security.json file to standalone mode. This was LONG after the
>>> feature was introduced in 5.2 and had a LOT of bugs fixed in the three
>>> 5.3.x releases.
>>>
>>> I just found the section in the documentation confirming what I
>>> suspected.
>>>
>>>
>> https://lucene.apache.org/solr/guide/7_2/authentication-and-authorization-plugins.html#authorization
>>>
>>> There is a note here that says "The authorization plugin is only
>>> supported in SolrCloud mode. Also, reloading the plugin isn’t yet
>>> supported and requires a restart of the Solr installation (meaning,
>>> the JVM should be restarted, not simply a core reload)." The 6.6
>>> documentation contains the same note that you can see here in the
>>> latest docs.
>>>
>>> I have no idea how hard it would be to extend the authorization plugin
>>> to support standalone cores as well as collections. I imagine that if
>>> it were easy, it would have been done already.
>>>
>>> Thanks,
>>> Shawn
>>>
>>>
>>
Re: Continuing Saga of Authorization on 6.6.0
Posted by Chris Ulicny <cu...@iq.media>.
> *failed to delete a user:*
"delete-user" is expecting an array of users in the json, so the data
should be: {"delete-user": ["lanny"]}
> *failed to set a permission: *
There are separate endpoints for authorization and authentication. You
should use ".../solr/admin/authorization" for the permissions instead of
"../solr/admin/authentication"
https://lucene.apache.org/solr/guide/7_2/rule-based-authorization-plugin.html#manage-permissions
Disclaimer: I've never worked with 6.6, but I've not noticed any big
differences between the security for our 6.3 deployments and the 7.X ones.
Best,
Chris
On Tue, Mar 13, 2018 at 12:47 PM Terry Steichen <te...@net-frame.com> wrote:
> I switched solr from standalone to cloud and created the two collections
> (emails1 and emails2).
>
> I was able to create a basic set of credentials via the curl-based
> API's. I could create users, and toggle the blockUnknown property
> status. However, the system refused to allow me to delete a user, or to
> set a permission.
>
> Here are the curl commands (with *terry:admin* as admin credentials) and
> results:
>
> *succeeded in setting blockUnknown property (verified by
> admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{
> "set-property": {"blockUnknown" : true}}'
>
> *succeeded in adding a user (verified by admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{
> > "set-user": {"lanny" : "hawaii"}}'
>
> *succeeded in changing lanny's password (verified by
> admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{
> "set-user": {"lanny" : "hawaii_five_o"}}'
>
> *failed to delete a user:*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{
> "delete-user": {"lanny"}}'
> {
> "responseHeader":{
> "status":500,
> "QTime":1},
>
> "error":{ "msg":"Expected key,value separator ':': char=},position=26
> BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
> [terry here: plus a very long stack trace}
>
> *failed to set a permission: *
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H <http://localhost:8983/solr/admin/authentication-H>
> 'Content-type:application/json' -d '{"set-permission" :
> {"name":"collection-admin-edit", "role":"admin"}}'
> {
> "responseHeader":{
> "status":0,
> "QTime":2},
> "errorMessages":[{
> "set-permission":{
> "name":"collection-admin-edit",
> "role":"admin"},
> "errorMessages":["Unknown operation 'set-permission' "]}]}
>
>
> This really makes no sense at all (or, I'm really losing it - always a
> distinct possibility). It's almost as if half of the documented
> parameters must have been changed, though I can't find any references to
> any such changes.
>
> I confess I'm about to just give up and find some other route to go.
>
> Terry
>
>
> On 03/12/2018 11:15 PM, Shawn Heisey wrote:
> > On 3/12/2018 8:39 PM, Terry Steichen wrote:
> >> I'm increasingly of the view that Solr's authentication/authorization
> >> mechanism doesn't work correctly in a _standalone_ mode. It was present
> >> in the cloud mode for quite a few versions back, but as of 6.0.0 (or so)
> >> it was supposed to be available in standalone mode too. It seems to
> >> partly work (when using the built-in permissions), but does not seem to
> >> work with customized, core-specific permissions.
> >
> > I suspected based on your last message that the authorization feature
> > might only work correctly in SolrCloud. The entire authentication
> > feature was designed for SolrCloud. Version 6.5 brought the
> > security.json file to standalone mode. This was LONG after the
> > feature was introduced in 5.2 and had a LOT of bugs fixed in the three
> > 5.3.x releases.
> >
> > I just found the section in the documentation confirming what I
> > suspected.
> >
> >
> https://lucene.apache.org/solr/guide/7_2/authentication-and-authorization-plugins.html#authorization
> >
> >
> > There is a note here that says "The authorization plugin is only
> > supported in SolrCloud mode. Also, reloading the plugin isn’t yet
> > supported and requires a restart of the Solr installation (meaning,
> > the JVM should be restarted, not simply a core reload)." The 6.6
> > documentation contains the same note that you can see here in the
> > latest docs.
> >
> > I have no idea how hard it would be to extend the authorization plugin
> > to support standalone cores as well as collections. I imagine that if
> > it were easy, it would have been done already.
> >
> > Thanks,
> > Shawn
> >
> >
>
>
Re: Continuing Saga of Authorization on 6.6.0
Posted by spoonerk <jo...@gmail.com>.
I wish unsubscribe worked
On Mar 13, 2018 9:47 AM, "Terry Steichen" <te...@net-frame.com> wrote:
> I switched solr from standalone to cloud and created the two collections
> (emails1 and emails2).
>
> I was able to create a basic set of credentials via the curl-based
> API's. I could create users, and toggle the blockUnknown property
> status. However, the system refused to allow me to delete a user, or to
> set a permission.
>
> Here are the curl commands (with *terry:admin* as admin credentials) and
> results:
>
> *succeeded in setting blockUnknown property (verified by
> admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{
> "set-property": {"blockUnknown" : true}}'
>
> *succeeded in adding a user (verified by admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{
> > "set-user": {"lanny" : "hawaii"}}'
>
> *succeeded in changing lanny's password (verified by
> admin/authentication dump):*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{
> "set-user": {"lanny" : "hawaii_five_o"}}'
>
> *failed to delete a user:*
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{
> "delete-user": {"lanny"}}'
> {
> "responseHeader":{
> "status":500,
> "QTime":1},
>
> "error":{ "msg":"Expected key,value separator ':': char=},position=26
> BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
> [terry here: plus a very long stack trace}
>
> *failed to set a permission: *
>
> curl --user terry:admin http://localhost:8983/solr/admin/authentication
> -H 'Content-type:application/json' -d '{"set-permission" :
> {"name":"collection-admin-edit", "role":"admin"}}'
> {
> "responseHeader":{
> "status":0,
> "QTime":2},
> "errorMessages":[{
> "set-permission":{
> "name":"collection-admin-edit",
> "role":"admin"},
> "errorMessages":["Unknown operation 'set-permission' "]}]}
>
>
> This really makes no sense at all (or, I'm really losing it - always a
> distinct possibility). It's almost as if half of the documented
> parameters must have been changed, though I can't find any references to
> any such changes.
>
> I confess I'm about to just give up and find some other route to go.
>
> Terry
>
>
> On 03/12/2018 11:15 PM, Shawn Heisey wrote:
> > On 3/12/2018 8:39 PM, Terry Steichen wrote:
> >> I'm increasingly of the view that Solr's authentication/authorization
> >> mechanism doesn't work correctly in a _standalone_ mode. It was present
> >> in the cloud mode for quite a few versions back, but as of 6.0.0 (or so)
> >> it was supposed to be available in standalone mode too. It seems to
> >> partly work (when using the built-in permissions), but does not seem to
> >> work with customized, core-specific permissions.
> >
> > I suspected based on your last message that the authorization feature
> > might only work correctly in SolrCloud. The entire authentication
> > feature was designed for SolrCloud. Version 6.5 brought the
> > security.json file to standalone mode. This was LONG after the
> > feature was introduced in 5.2 and had a LOT of bugs fixed in the three
> > 5.3.x releases.
> >
> > I just found the section in the documentation confirming what I
> > suspected.
> >
> > https://lucene.apache.org/solr/guide/7_2/authentication-
> and-authorization-plugins.html#authorization
> >
> >
> > There is a note here that says "The authorization plugin is only
> > supported in SolrCloud mode. Also, reloading the plugin isn’t yet
> > supported and requires a restart of the Solr installation (meaning,
> > the JVM should be restarted, not simply a core reload)." The 6.6
> > documentation contains the same note that you can see here in the
> > latest docs.
> >
> > I have no idea how hard it would be to extend the authorization plugin
> > to support standalone cores as well as collections. I imagine that if
> > it were easy, it would have been done already.
> >
> > Thanks,
> > Shawn
> >
> >
>
>
Continuing Saga of Authorization on 6.6.0
Posted by Terry Steichen <te...@net-frame.com>.
I switched solr from standalone to cloud and created the two collections
(emails1 and emails2).
I was able to create a basic set of credentials via the curl-based
API's. I could create users, and toggle the blockUnknown property
status. However, the system refused to allow me to delete a user, or to
set a permission.
Here are the curl commands (with *terry:admin* as admin credentials) and
results:
*succeeded in setting blockUnknown property (verified by
admin/authentication dump):*
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{
"set-property": {"blockUnknown" : true}}'
*succeeded in adding a user (verified by admin/authentication dump):*
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{
> "set-user": {"lanny" : "hawaii"}}'
*succeeded in changing lanny's password (verified by
admin/authentication dump):*
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{
"set-user": {"lanny" : "hawaii_five_o"}}'
*failed to delete a user:*
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{
"delete-user": {"lanny"}}'
{
"responseHeader":{
"status":500,
"QTime":1},
"error":{ "msg":"Expected key,value separator ':': char=},position=26
BEFORE='{ \"delete-user\": {\"lanny\"}' AFTER='}'",
[terry here: plus a very long stack trace}
*failed to set a permission: *
curl --user terry:admin http://localhost:8983/solr/admin/authentication
-H 'Content-type:application/json' -d '{"set-permission" :
{"name":"collection-admin-edit", "role":"admin"}}'
{
"responseHeader":{
"status":0,
"QTime":2},
"errorMessages":[{
"set-permission":{
"name":"collection-admin-edit",
"role":"admin"},
"errorMessages":["Unknown operation 'set-permission' "]}]}
This really makes no sense at all (or, I'm really losing it - always a
distinct possibility). It's almost as if half of the documented
parameters must have been changed, though I can't find any references to
any such changes.
I confess I'm about to just give up and find some other route to go.
Terry
On 03/12/2018 11:15 PM, Shawn Heisey wrote:
> On 3/12/2018 8:39 PM, Terry Steichen wrote:
>> I'm increasingly of the view that Solr's authentication/authorization
>> mechanism doesn't work correctly in a _standalone_ mode. It was present
>> in the cloud mode for quite a few versions back, but as of 6.0.0 (or so)
>> it was supposed to be available in standalone mode too. It seems to
>> partly work (when using the built-in permissions), but does not seem to
>> work with customized, core-specific permissions.
>
> I suspected based on your last message that the authorization feature
> might only work correctly in SolrCloud. The entire authentication
> feature was designed for SolrCloud. Version 6.5 brought the
> security.json file to standalone mode. This was LONG after the
> feature was introduced in 5.2 and had a LOT of bugs fixed in the three
> 5.3.x releases.
>
> I just found the section in the documentation confirming what I
> suspected.
>
> https://lucene.apache.org/solr/guide/7_2/authentication-and-authorization-plugins.html#authorization
>
>
> There is a note here that says "The authorization plugin is only
> supported in SolrCloud mode. Also, reloading the plugin isn’t yet
> supported and requires a restart of the Solr installation (meaning,
> the JVM should be restarted, not simply a core reload)." The 6.6
> documentation contains the same note that you can see here in the
> latest docs.
>
> I have no idea how hard it would be to extend the authorization plugin
> to support standalone cores as well as collections. I imagine that if
> it were easy, it would have been done already.
>
> Thanks,
> Shawn
>
>
Re: Resend: Authorization on 6.6.0
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/12/2018 8:39 PM, Terry Steichen wrote:
> I'm increasingly of the view that Solr's authentication/authorization
> mechanism doesn't work correctly in a _standalone_ mode. It was present
> in the cloud mode for quite a few versions back, but as of 6.0.0 (or so)
> it was supposed to be available in standalone mode too. It seems to
> partly work (when using the built-in permissions), but does not seem to
> work with customized, core-specific permissions.
I suspected based on your last message that the authorization feature
might only work correctly in SolrCloud. The entire authentication
feature was designed for SolrCloud. Version 6.5 brought the
security.json file to standalone mode. This was LONG after the feature
was introduced in 5.2 and had a LOT of bugs fixed in the three 5.3.x
releases.
I just found the section in the documentation confirming what I suspected.
https://lucene.apache.org/solr/guide/7_2/authentication-and-authorization-plugins.html#authorization
There is a note here that says "The authorization plugin is only
supported in SolrCloud mode. Also, reloading the plugin isn’t yet
supported and requires a restart of the Solr installation (meaning, the
JVM should be restarted, not simply a core reload)." The 6.6
documentation contains the same note that you can see here in the latest
docs.
I have no idea how hard it would be to extend the authorization plugin
to support standalone cores as well as collections. I imagine that if
it were easy, it would have been done already.
Thanks,
Shawn
Re: Resend: Authorization on 6.6.0
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/12/2018 4:07 PM, Terry Steichen wrote:
> I'm using 6.6.0 with security.json active, having the content shown
> below. I am running standalone mode, have two solr cores defined:
> email1, and email2. Since the 'blockUnknown' is set to false, everyone
> should have access to any unprotected resource. As you can see, I have
> three users defined: joe, solr and terry (the latter two having an admin
> role).
>
> What I expect to happen is for user joe (who is not an admin) to be able
> to access core emails2 without being challenged for his credentials.
> But, user joe should also be challenged and not allowed to access emails1.
>
> But solr appears to ignore the "collections" portion of the permission -
> it denies joe access to both cores.
<snip>
> "blockUnknown": true,
Above you said that blockUnknown was false. But in the config that
you've included here, I can clearly see it set to true. Could that be
the issue?
I don't actually know anything about the authentication/authorization
plugin configuration. But I can spot a discrepancy!
I can see in your original email, where the config got formatted badly,
that it was false. So which is actually there?
Thanks,
Shawn
RE: Resend: Authorization on 6.6.0
Posted by "Davis, Daniel (NIH/NLM) [C]" <da...@nih.gov>.
I believe that Joe needs to be given some level of access for him to be able to see the collections, and joe should always be required to give his/her/its password to access any collection.
-----Original Message-----
From: Terry Steichen [mailto:terry@net-frame.com]
Sent: Monday, March 12, 2018 6:08 PM
To: solr-user@lucene.apache.org
Subject: Resend: Authorization on 6.6.0
I'm resending the information below because the original message got the security.json stuff garbled.
--------------------------------------------------------------------------------
I'm using 6.6.0 with security.json active, having the content shown below. I am running standalone mode, have two solr cores defined:
email1, and email2. Since the 'blockUnknown' is set to false, everyone should have access to any unprotected resource. As you can see, I have three users defined: joe, solr and terry (the latter two having an admin role).
What I expect to happen is for user joe (who is not an admin) to be able to access core emails2 without being challenged for his credentials. But, user joe should also be challenged and not allowed to access emails1.
But solr appears to ignore the "collections" portion of the permission - it denies joe access to both cores.
Is this a bug (in that auth doesn't work properly in 6.6.0 standalone), or am I (once again) missing something?
Terry
{
"authentication": {
"class": "solr.BasicAuthPlugin",
"blockUnknown": true,
"credentials": {
"solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c=",
"joe": "iGx0BaTgmjmCxrRmaD3IsCb2MJ21x1vqhfdzbwyu9MY=
P+aA0Bx811jzRwR97bOn/x/jyvpoKiHpWIRRXGAc8tg=",
"terry": "q71fVfo/DIeCSfc1zw6YMyXVjU24Jr2oLniEkXFdPe0=
oSaEbu/0TCg8UehLQ9zfoH3AvrJBqCaIoJkt547WIrc="
},
"": {
"v": 0
}
},
"authorization": {
"class": "solr.RuleBasedAuthorizationPlugin",
"user-role": {
"solr": "admin",
"terry": "admin"
},
"permissions": [
{
"path": "/select",
"role": "admin"
}
]
}
}