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 "Vaillancourt, Tim" <TV...@ea.com> on 2013/03/29 01:42:45 UTC
Basic auth on SolrCloud /admin/* calls
Hey guys,
I've recently setup basic auth under Jetty 8 for all my Solr 4.x '/admin/*' calls, in order to protect my Collections and Cores API.
Although the security constraint is working as expected ('/admin/*' calls require Basic Auth or return 401), when I use the Collections API to create a collection, I receive a 200 OK to the Collections API CREATE call, but the background Cores API calls that are ran on the Collection API's behalf fail on the Basic Auth on other nodes with a 401 code, as I should have foreseen, but didn't.
Is there a way to tell SolrCloud to use authentication on internal Cores API calls that are spawned on Collections API's behalf, or is this a new feature request?
To reproduce:
1. Implement basic auth on '/admin/*' URIs.
2. Perform a CREATE Collections API call to a node (which will return 200 OK).
3. Notice all Cores API calls fail (Collection isn't created). See stack trace below from the node that was issued the CREATE call.
The stack trace I get is:
"org.apache.solr.common.SolrException: Server at http://<HOST HERE>:8983/solr<http://%3cHOST%20HERE%3e:8983/solr> returned non ok status:401, message:Unauthorized
at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:373)
at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:181)
at org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:169)
at org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:135)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)"
Cheers!
Tim
Re: Basic auth on SolrCloud /admin/* calls
Posted by rulinma <ru...@gmail.com>.
mark
--
View this message in context: http://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4155521.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Basic auth on SolrCloud /admin/* calls
Posted by Gopal Patwa <go...@gmail.com>.
I was looking too for this feature and it seems SOLR-4470 can work but I
haven't tried yet.
+1
On Sun, Apr 14, 2013 at 12:14 PM, Tim Vaillancourt <ti...@elementspace.com>wrote:
> I've thought about this too, and have heard of some people running a
> lightweight http proxy upstream of Solr.
>
> With the right network restrictions (only way for a client to reach solr
> is via a proxy + the nodes can still talk to each other), you could achieve
> the same thing SOLR-4470 is doing, with the drawback of additional proxy
> and firewall components to maintain, plus added overhead on HTTP calls.
>
> A benefit though is a lightweight proxy ahead of Solr could implement HTTP
> caching, taking some load off of Solr.
>
> In a perfect world, I'd say rolling out SOLR-4470 is the best solution,
> but again, it seems to be losing momentum (please Vote/support the
> discussion!). While proxies can achieve this, I think enough people have
> pondered about this to implement this as a feature in Solr.
>
> Tim
>
>
> On 14/04/13 12:32 AM, adfel70 wrote:
>
>> Did anyone try blocking access to the ports in the firewall level, and
>> allowing all the solr servers in the cluster+given control-machines?
>> Assuming that search request to solr run though a proxy..
>>
>>
>>
>>
>>
>> --
>> View this message in context: http://lucene.472066.n3.**
>> nabble.com/Basic-auth-on-**SolrCloud-admin-calls-**tp4052266p4055868.html<http://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4055868.html>
>> Sent from the Solr - User mailing list archive at Nabble.com.
>>
>
Re: Basic auth on SolrCloud /admin/* calls
Posted by Tim Vaillancourt <ti...@elementspace.com>.
I've thought about this too, and have heard of some people running a
lightweight http proxy upstream of Solr.
With the right network restrictions (only way for a client to reach solr
is via a proxy + the nodes can still talk to each other), you could
achieve the same thing SOLR-4470 is doing, with the drawback of
additional proxy and firewall components to maintain, plus added
overhead on HTTP calls.
A benefit though is a lightweight proxy ahead of Solr could implement
HTTP caching, taking some load off of Solr.
In a perfect world, I'd say rolling out SOLR-4470 is the best solution,
but again, it seems to be losing momentum (please Vote/support the
discussion!). While proxies can achieve this, I think enough people have
pondered about this to implement this as a feature in Solr.
Tim
On 14/04/13 12:32 AM, adfel70 wrote:
> Did anyone try blocking access to the ports in the firewall level, and
> allowing all the solr servers in the cluster+given control-machines?
> Assuming that search request to solr run though a proxy..
>
>
>
>
>
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4055868.html
> Sent from the Solr - User mailing list archive at Nabble.com.
Re: Basic auth on SolrCloud /admin/* calls
Posted by adfel70 <ad...@gmail.com>.
Did anyone try blocking access to the ports in the firewall level, and
allowing all the solr servers in the cluster+given control-machines?
Assuming that search request to solr run though a proxy..
--
View this message in context: http://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4055868.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Basic auth on SolrCloud /admin/* calls
Posted by Tim Vaillancourt <ti...@elementspace.com>.
This JIRA covers a lot of what you're asking:
https://issues.apache.org/jira/browse/SOLR-4470
I am also trying to get this sort of solution in place, but it seems to
be dying off a bit. Hopefully we can get some interest on this again,
this question comes up every few weeks, it seems.
I can confirm the latest patch from this JIRA works as expected,
although my primary concern is the credentials appear in the JVM
command, and I'd like to move that to a file.
Cheers,
Tim
On 11/04/13 10:41 AM, Michael Della Bitta wrote:
> It's fairly easy to lock down Solr behind basic auth using just the
> servlet container it's running in, but the problem becomes letting
> services that *should* be able to access Solr in. I've rolled with
> basic auth in some setups, but certain deployments such as Solr Cloud
> or sharded setups don't play well with auth because there's no good
> way to configure them to use it.
>
> Michael Della Bitta
>
> ------------------------------------------------
> Appinions
> 18 East 41st Street, 2nd Floor
> New York, NY 10017-6271
>
> www.appinions.com
>
> Where Influence Isn’t a Game
>
>
> On Thu, Apr 11, 2013 at 1:19 PM, Raymond Wiker<rw...@gmail.com> wrote:
>> On Apr 11, 2013, at 17:12 , adfel70<ad...@gmail.com> wrote:
>>> Hi
>>> I need to implement security in solr as follows:
>>> 1. prevent unauthorized users from accessing to solr admin pages.
>>> 2. prevent unauthorized users from performing solr operations - both /admin
>>> and /update.
>>>
>>>
>>> Is the conclusion of this thread is that this is not possible at the moment?
>>
>> The "obvious" solution (to me, at least) would be to (1) restrict access to solr to localhost, and (2) use a reverse proxy (e.g, apache) on the same node to provide authenticated& restricted access to solr. I think I've seen recipes for (1), somewhere, and I've used (2) fairly extensively for similar purposes.
Re: Basic auth on SolrCloud /admin/* calls
Posted by Michael Della Bitta <mi...@appinions.com>.
It's fairly easy to lock down Solr behind basic auth using just the
servlet container it's running in, but the problem becomes letting
services that *should* be able to access Solr in. I've rolled with
basic auth in some setups, but certain deployments such as Solr Cloud
or sharded setups don't play well with auth because there's no good
way to configure them to use it.
Michael Della Bitta
------------------------------------------------
Appinions
18 East 41st Street, 2nd Floor
New York, NY 10017-6271
www.appinions.com
Where Influence Isn’t a Game
On Thu, Apr 11, 2013 at 1:19 PM, Raymond Wiker <rw...@gmail.com> wrote:
> On Apr 11, 2013, at 17:12 , adfel70 <ad...@gmail.com> wrote:
>> Hi
>> I need to implement security in solr as follows:
>> 1. prevent unauthorized users from accessing to solr admin pages.
>> 2. prevent unauthorized users from performing solr operations - both /admin
>> and /update.
>>
>>
>> Is the conclusion of this thread is that this is not possible at the moment?
>
>
> The "obvious" solution (to me, at least) would be to (1) restrict access to solr to localhost, and (2) use a reverse proxy (e.g, apache) on the same node to provide authenticated & restricted access to solr. I think I've seen recipes for (1), somewhere, and I've used (2) fairly extensively for similar purposes.
Re: Basic auth on SolrCloud /admin/* calls
Posted by Raymond Wiker <rw...@gmail.com>.
On Apr 11, 2013, at 17:12 , adfel70 <ad...@gmail.com> wrote:
> Hi
> I need to implement security in solr as follows:
> 1. prevent unauthorized users from accessing to solr admin pages.
> 2. prevent unauthorized users from performing solr operations - both /admin
> and /update.
>
>
> Is the conclusion of this thread is that this is not possible at the moment?
The "obvious" solution (to me, at least) would be to (1) restrict access to solr to localhost, and (2) use a reverse proxy (e.g, apache) on the same node to provide authenticated & restricted access to solr. I think I've seen recipes for (1), somewhere, and I've used (2) fairly extensively for similar purposes.
RE: Basic auth on SolrCloud /admin/* calls
Posted by adfel70 <ad...@gmail.com>.
Hi
I need to implement security in solr as follows:
1. prevent unauthorized users from accessing to solr admin pages.
2. prevent unauthorized users from performing solr operations - both /admin
and /update.
Is the conclusion of this thread is that this is not possible at the moment?
--
View this message in context: http://lucene.472066.n3.nabble.com/Basic-auth-on-SolrCloud-admin-calls-tp4052266p4055330.html
Sent from the Solr - User mailing list archive at Nabble.com.
RE: Basic auth on SolrCloud /admin/* calls
Posted by "Vaillancourt, Tim" <TV...@ea.com>.
Here we go:
https://issues.apache.org/jira/browse/SOLR-4470
Tim
-----Original Message-----
From: Vaillancourt, Tim [mailto:TVaillancourt@ea.com]
Sent: Friday, March 29, 2013 3:25 PM
To: solr-user@lucene.apache.org
Subject: RE: Basic auth on SolrCloud /admin/* calls
Agreed, we don't have clients hitting Solr directly, it is used like a backend database in our usage by intermediaries, similar to say MySQL. Although restricting the access to Solr to fewer hosts is something, I still feel an application has no business being able to perform admin level calls, at least in my use case. This is being very nitpicky though.
We also open Solr's port to monitoring servers who shouldn't have access to admin calls and thinking paranoid a compromised app using a single collection could affect the entire cloud with admin call access.
Seeing the long term plan is to leave this feature at the container level (which is totally valid), I think I'll continue with the basic auth approach I attempted and see what I can dig up on past efforts. I'll be sure to share what I've done.
Thanks Mark!
Tim
-----Original Message-----
From: Mark Miller [mailto:markrmiller@gmail.com]
Sent: Friday, March 29, 2013 1:04 PM
To: solr-user@lucene.apache.org
Subject: Re: Basic auth on SolrCloud /admin/* calls
This has always been the case with Solr. Solr's security model is that clients should not have access to it - only trusted intermediaries should have access to it. Otherwise, it should be locked down at a higher level. That's been the case from day one and still is.
That said, someone did do some work on internode basic auth a while back, but it didn't raise a ton of interest yet.
- Mark
On Mar 29, 2013, at 2:09 PM, "Vaillancourt, Tim" <TV...@ea.com> wrote:
> Yes, I should have mentioned this is under 4.2 Solr.
>
> I sort of expected what I'm doing might be unsupported, but basically my concern is under the current SOLR design, any client with connectivity to SOLR's port can perform Admin-level API calls like create/drop Cores or Collections.
>
> I'm only aiming for '/solr/admin/*' calls to separate "Application" access from the "Administrative" access logically, and not the non-admin calls like '/update', although you can cause damage with '/update', too.
>
> I may try to patch the code to send Basic auth credentials on internal calls just for fun, but I'm thinking longer-term authentication should be implemented/added to the SOLR codebase (for at least admin calls) vs playing with security at the container level, and having the app inside the container aware of it.
>
> On the upside, in short testing I was able to get a Collection online using Cores API only using curl calls w/basic auth. Only the Collections API is affected due to it calls itself which do not have auth.
>
> Cheers,
>
> Tim
>
> -----Original Message-----
> From: Isaac Hebsh [mailto:isaac.hebsh@gmail.com]
> Sent: Friday, March 29, 2013 12:37 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Basic auth on SolrCloud /admin/* calls
>
> Hi Tim,
> Are you running Solr 4.2? (In 4.0 and 4.1, the Collections API didn't return any failure message. see SOLR-4043 issue).
>
> As far as I know, you can't tell Solr to use authentication credentials when communicating other nodes. It's a bigger issue.. for example, if you want to protect the "/update" requestHandler, so unauthorized users won't delete your whole collection, it can interfere the replication process.
>
> I think it's a necessary mechanism in production environment... I'm curious how do people use SolrCloud in production w/o it.
>
>
>
>
>
> On Fri, Mar 29, 2013 at 3:42 AM, Vaillancourt, Tim <TV...@ea.com>wrote:
>
>> Hey guys,
>>
>> I've recently setup basic auth under Jetty 8 for all my Solr 4.x
>> '/admin/*' calls, in order to protect my Collections and Cores API.
>>
>> Although the security constraint is working as expected ('/admin/*'
>> calls require Basic Auth or return 401), when I use the Collections
>> API to create a collection, I receive a 200 OK to the Collections API
>> CREATE call, but the background Cores API calls that are ran on the
>> Collection API's behalf fail on the Basic Auth on other nodes with a
>> 401 code, as I should have foreseen, but didn't.
>>
>> Is there a way to tell SolrCloud to use authentication on internal
>> Cores API calls that are spawned on Collections API's behalf, or is
>> this a new feature request?
>>
>> To reproduce:
>>
>> 1. Implement basic auth on '/admin/*' URIs.
>>
>> 2. Perform a CREATE Collections API call to a node (which will
>> return 200 OK).
>>
>> 3. Notice all Cores API calls fail (Collection isn't created). See
>> stack trace below from the node that was issued the CREATE call.
>>
>> The stack trace I get is:
>>
>> "org.apache.solr.common.SolrException: Server at http://<HOST
>> HERE>:8983/solr<http://%3cHOST%20HERE%3e:8983/solr> returned non ok
>> status:401, message:Unauthorized
>> at
>> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServ
>> e
>> r.java:373)
>> at
>> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServ
>> e
>> r.java:181)
>> at
>> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHa
>> n
>> dler.java:169)
>> at
>> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHa
>> n
>> dler.java:135) at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:43
>> 9
>> ) at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
>> u
>> tor.java:895)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
>> java:918) at java.lang.Thread.run(Thread.java:662)"
>>
>> Cheers!
>>
>> Tim
>>
>>
>>
RE: Basic auth on SolrCloud /admin/* calls
Posted by "Vaillancourt, Tim" <TV...@ea.com>.
Agreed, we don't have clients hitting Solr directly, it is used like a backend database in our usage by intermediaries, similar to say MySQL. Although restricting the access to Solr to fewer hosts is something, I still feel an application has no business being able to perform admin level calls, at least in my use case. This is being very nitpicky though.
We also open Solr's port to monitoring servers who shouldn't have access to admin calls and thinking paranoid a compromised app using a single collection could affect the entire cloud with admin call access.
Seeing the long term plan is to leave this feature at the container level (which is totally valid), I think I'll continue with the basic auth approach I attempted and see what I can dig up on past efforts. I'll be sure to share what I've done.
Thanks Mark!
Tim
-----Original Message-----
From: Mark Miller [mailto:markrmiller@gmail.com]
Sent: Friday, March 29, 2013 1:04 PM
To: solr-user@lucene.apache.org
Subject: Re: Basic auth on SolrCloud /admin/* calls
This has always been the case with Solr. Solr's security model is that clients should not have access to it - only trusted intermediaries should have access to it. Otherwise, it should be locked down at a higher level. That's been the case from day one and still is.
That said, someone did do some work on internode basic auth a while back, but it didn't raise a ton of interest yet.
- Mark
On Mar 29, 2013, at 2:09 PM, "Vaillancourt, Tim" <TV...@ea.com> wrote:
> Yes, I should have mentioned this is under 4.2 Solr.
>
> I sort of expected what I'm doing might be unsupported, but basically my concern is under the current SOLR design, any client with connectivity to SOLR's port can perform Admin-level API calls like create/drop Cores or Collections.
>
> I'm only aiming for '/solr/admin/*' calls to separate "Application" access from the "Administrative" access logically, and not the non-admin calls like '/update', although you can cause damage with '/update', too.
>
> I may try to patch the code to send Basic auth credentials on internal calls just for fun, but I'm thinking longer-term authentication should be implemented/added to the SOLR codebase (for at least admin calls) vs playing with security at the container level, and having the app inside the container aware of it.
>
> On the upside, in short testing I was able to get a Collection online using Cores API only using curl calls w/basic auth. Only the Collections API is affected due to it calls itself which do not have auth.
>
> Cheers,
>
> Tim
>
> -----Original Message-----
> From: Isaac Hebsh [mailto:isaac.hebsh@gmail.com]
> Sent: Friday, March 29, 2013 12:37 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Basic auth on SolrCloud /admin/* calls
>
> Hi Tim,
> Are you running Solr 4.2? (In 4.0 and 4.1, the Collections API didn't return any failure message. see SOLR-4043 issue).
>
> As far as I know, you can't tell Solr to use authentication credentials when communicating other nodes. It's a bigger issue.. for example, if you want to protect the "/update" requestHandler, so unauthorized users won't delete your whole collection, it can interfere the replication process.
>
> I think it's a necessary mechanism in production environment... I'm curious how do people use SolrCloud in production w/o it.
>
>
>
>
>
> On Fri, Mar 29, 2013 at 3:42 AM, Vaillancourt, Tim <TV...@ea.com>wrote:
>
>> Hey guys,
>>
>> I've recently setup basic auth under Jetty 8 for all my Solr 4.x
>> '/admin/*' calls, in order to protect my Collections and Cores API.
>>
>> Although the security constraint is working as expected ('/admin/*'
>> calls require Basic Auth or return 401), when I use the Collections
>> API to create a collection, I receive a 200 OK to the Collections API
>> CREATE call, but the background Cores API calls that are ran on the
>> Collection API's behalf fail on the Basic Auth on other nodes with a
>> 401 code, as I should have foreseen, but didn't.
>>
>> Is there a way to tell SolrCloud to use authentication on internal
>> Cores API calls that are spawned on Collections API's behalf, or is
>> this a new feature request?
>>
>> To reproduce:
>>
>> 1. Implement basic auth on '/admin/*' URIs.
>>
>> 2. Perform a CREATE Collections API call to a node (which will
>> return 200 OK).
>>
>> 3. Notice all Cores API calls fail (Collection isn't created). See
>> stack trace below from the node that was issued the CREATE call.
>>
>> The stack trace I get is:
>>
>> "org.apache.solr.common.SolrException: Server at http://<HOST
>> HERE>:8983/solr<http://%3cHOST%20HERE%3e:8983/solr> returned non ok
>> status:401, message:Unauthorized
>> at
>> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServ
>> e
>> r.java:373)
>> at
>> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServ
>> e
>> r.java:181)
>> at
>> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHa
>> n
>> dler.java:169)
>> at
>> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHa
>> n
>> dler.java:135) at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:43
>> 9
>> ) at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
>> u
>> tor.java:895)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
>> java:918) at java.lang.Thread.run(Thread.java:662)"
>>
>> Cheers!
>>
>> Tim
>>
>>
>>
Re: Basic auth on SolrCloud /admin/* calls
Posted by Mark Miller <ma...@gmail.com>.
This has always been the case with Solr. Solr's security model is that clients should not have access to it - only trusted intermediaries should have access to it. Otherwise, it should be locked down at a higher level. That's been the case from day one and still is.
That said, someone did do some work on internode basic auth a while back, but it didn't raise a ton of interest yet.
- Mark
On Mar 29, 2013, at 2:09 PM, "Vaillancourt, Tim" <TV...@ea.com> wrote:
> Yes, I should have mentioned this is under 4.2 Solr.
>
> I sort of expected what I'm doing might be unsupported, but basically my concern is under the current SOLR design, any client with connectivity to SOLR's port can perform Admin-level API calls like create/drop Cores or Collections.
>
> I'm only aiming for '/solr/admin/*' calls to separate "Application" access from the "Administrative" access logically, and not the non-admin calls like '/update', although you can cause damage with '/update', too.
>
> I may try to patch the code to send Basic auth credentials on internal calls just for fun, but I'm thinking longer-term authentication should be implemented/added to the SOLR codebase (for at least admin calls) vs playing with security at the container level, and having the app inside the container aware of it.
>
> On the upside, in short testing I was able to get a Collection online using Cores API only using curl calls w/basic auth. Only the Collections API is affected due to it calls itself which do not have auth.
>
> Cheers,
>
> Tim
>
> -----Original Message-----
> From: Isaac Hebsh [mailto:isaac.hebsh@gmail.com]
> Sent: Friday, March 29, 2013 12:37 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Basic auth on SolrCloud /admin/* calls
>
> Hi Tim,
> Are you running Solr 4.2? (In 4.0 and 4.1, the Collections API didn't return any failure message. see SOLR-4043 issue).
>
> As far as I know, you can't tell Solr to use authentication credentials when communicating other nodes. It's a bigger issue.. for example, if you want to protect the "/update" requestHandler, so unauthorized users won't delete your whole collection, it can interfere the replication process.
>
> I think it's a necessary mechanism in production environment... I'm curious how do people use SolrCloud in production w/o it.
>
>
>
>
>
> On Fri, Mar 29, 2013 at 3:42 AM, Vaillancourt, Tim <TV...@ea.com>wrote:
>
>> Hey guys,
>>
>> I've recently setup basic auth under Jetty 8 for all my Solr 4.x
>> '/admin/*' calls, in order to protect my Collections and Cores API.
>>
>> Although the security constraint is working as expected ('/admin/*'
>> calls require Basic Auth or return 401), when I use the Collections
>> API to create a collection, I receive a 200 OK to the Collections API
>> CREATE call, but the background Cores API calls that are ran on the
>> Collection API's behalf fail on the Basic Auth on other nodes with a
>> 401 code, as I should have foreseen, but didn't.
>>
>> Is there a way to tell SolrCloud to use authentication on internal
>> Cores API calls that are spawned on Collections API's behalf, or is
>> this a new feature request?
>>
>> To reproduce:
>>
>> 1. Implement basic auth on '/admin/*' URIs.
>>
>> 2. Perform a CREATE Collections API call to a node (which will
>> return 200 OK).
>>
>> 3. Notice all Cores API calls fail (Collection isn't created). See
>> stack trace below from the node that was issued the CREATE call.
>>
>> The stack trace I get is:
>>
>> "org.apache.solr.common.SolrException: Server at http://<HOST
>> HERE>:8983/solr<http://%3cHOST%20HERE%3e:8983/solr> returned non ok
>> status:401, message:Unauthorized
>> at
>> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServe
>> r.java:373)
>> at
>> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServe
>> r.java:181)
>> at
>> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHan
>> dler.java:169)
>> at
>> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHan
>> dler.java:135) at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439
>> ) at
>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu
>> tor.java:895)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
>> java:918) at java.lang.Thread.run(Thread.java:662)"
>>
>> Cheers!
>>
>> Tim
>>
>>
>>
RE: Basic auth on SolrCloud /admin/* calls
Posted by "Vaillancourt, Tim" <TV...@ea.com>.
Yes, I should have mentioned this is under 4.2 Solr.
I sort of expected what I'm doing might be unsupported, but basically my concern is under the current SOLR design, any client with connectivity to SOLR's port can perform Admin-level API calls like create/drop Cores or Collections.
I'm only aiming for '/solr/admin/*' calls to separate "Application" access from the "Administrative" access logically, and not the non-admin calls like '/update', although you can cause damage with '/update', too.
I may try to patch the code to send Basic auth credentials on internal calls just for fun, but I'm thinking longer-term authentication should be implemented/added to the SOLR codebase (for at least admin calls) vs playing with security at the container level, and having the app inside the container aware of it.
On the upside, in short testing I was able to get a Collection online using Cores API only using curl calls w/basic auth. Only the Collections API is affected due to it calls itself which do not have auth.
Cheers,
Tim
-----Original Message-----
From: Isaac Hebsh [mailto:isaac.hebsh@gmail.com]
Sent: Friday, March 29, 2013 12:37 AM
To: solr-user@lucene.apache.org
Subject: Re: Basic auth on SolrCloud /admin/* calls
Hi Tim,
Are you running Solr 4.2? (In 4.0 and 4.1, the Collections API didn't return any failure message. see SOLR-4043 issue).
As far as I know, you can't tell Solr to use authentication credentials when communicating other nodes. It's a bigger issue.. for example, if you want to protect the "/update" requestHandler, so unauthorized users won't delete your whole collection, it can interfere the replication process.
I think it's a necessary mechanism in production environment... I'm curious how do people use SolrCloud in production w/o it.
On Fri, Mar 29, 2013 at 3:42 AM, Vaillancourt, Tim <TV...@ea.com>wrote:
> Hey guys,
>
> I've recently setup basic auth under Jetty 8 for all my Solr 4.x
> '/admin/*' calls, in order to protect my Collections and Cores API.
>
> Although the security constraint is working as expected ('/admin/*'
> calls require Basic Auth or return 401), when I use the Collections
> API to create a collection, I receive a 200 OK to the Collections API
> CREATE call, but the background Cores API calls that are ran on the
> Collection API's behalf fail on the Basic Auth on other nodes with a
> 401 code, as I should have foreseen, but didn't.
>
> Is there a way to tell SolrCloud to use authentication on internal
> Cores API calls that are spawned on Collections API's behalf, or is
> this a new feature request?
>
> To reproduce:
>
> 1. Implement basic auth on '/admin/*' URIs.
>
> 2. Perform a CREATE Collections API call to a node (which will
> return 200 OK).
>
> 3. Notice all Cores API calls fail (Collection isn't created). See
> stack trace below from the node that was issued the CREATE call.
>
> The stack trace I get is:
>
> "org.apache.solr.common.SolrException: Server at http://<HOST
> HERE>:8983/solr<http://%3cHOST%20HERE%3e:8983/solr> returned non ok
> status:401, message:Unauthorized
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServe
> r.java:373)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServe
> r.java:181)
> at
> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHan
> dler.java:169)
> at
> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHan
> dler.java:135) at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439
> ) at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu
> tor.java:895)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:918) at java.lang.Thread.run(Thread.java:662)"
>
> Cheers!
>
> Tim
>
>
>
Re: Basic auth on SolrCloud /admin/* calls
Posted by Isaac Hebsh <is...@gmail.com>.
Hi Tim,
Are you running Solr 4.2? (In 4.0 and 4.1, the Collections API didn't
return any failure message. see SOLR-4043 issue).
As far as I know, you can't tell Solr to use authentication credentials
when communicating other nodes. It's a bigger issue.. for example, if you
want to protect the "/update" requestHandler, so unauthorized users won't
delete your whole collection, it can interfere the replication process.
I think it's a necessary mechanism in production environment... I'm curious
how do people use SolrCloud in production w/o it.
On Fri, Mar 29, 2013 at 3:42 AM, Vaillancourt, Tim <TV...@ea.com>wrote:
> Hey guys,
>
> I've recently setup basic auth under Jetty 8 for all my Solr 4.x
> '/admin/*' calls, in order to protect my Collections and Cores API.
>
> Although the security constraint is working as expected ('/admin/*' calls
> require Basic Auth or return 401), when I use the Collections API to create
> a collection, I receive a 200 OK to the Collections API CREATE call, but
> the background Cores API calls that are ran on the Collection API's behalf
> fail on the Basic Auth on other nodes with a 401 code, as I should have
> foreseen, but didn't.
>
> Is there a way to tell SolrCloud to use authentication on internal Cores
> API calls that are spawned on Collections API's behalf, or is this a new
> feature request?
>
> To reproduce:
>
> 1. Implement basic auth on '/admin/*' URIs.
>
> 2. Perform a CREATE Collections API call to a node (which will
> return 200 OK).
>
> 3. Notice all Cores API calls fail (Collection isn't created). See
> stack trace below from the node that was issued the CREATE call.
>
> The stack trace I get is:
>
> "org.apache.solr.common.SolrException: Server at http://<HOST
> HERE>:8983/solr<http://%3cHOST%20HERE%3e:8983/solr> returned non ok
> status:401, message:Unauthorized
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:373)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:181)
> at
> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:169)
> at
> org.apache.solr.handler.component.HttpShardHandler$1.call(HttpShardHandler.java:135)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)"
>
> Cheers!
>
> Tim
>
>
>