Here we go: https://issues.apache.org/jira/browse/SOLR-4470
Tim -----Original Message----- From: Vaillancourt, Tim [mailto:tvaillanco...@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:markrmil...@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" <tvaillanco...@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.he...@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 > <tvaillanco...@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 >> >> >>
