On Tue, Feb 23, 2010 at 10:09 AM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote:
> On Mon, Feb 22, 2010 at 5:43 PM, Jorg Heymans <jorg.heym...@gmail.com > >wrote: > > > > > What is the recommended pattern for securing a multicore solr instance, > > accessed by different applications ? In our case, we need to prevent > > application A from accessing the core of application B. Also, we need to > > avoid the use of username/password authentication wherever possible. I > have > > read the wiki page on solr security and it talks about path based > > authentication, but both DIGEST and BASIC auth are username/password > based > > so i'm looking for alternatives. > > > > One idea i had was to use https and create a x509 cert per application, > > with > > a different subject per application. Then on the solr server i would > > somehow > > need to extend the component that is responsible for delegating > > /sorl/appA/* > > to the appA request handlers (is there such thing even ?) and verify that > > requests for /appA are done over https with a valid certificate that has > > /appA as subject. Is this feasible ? Or maybe there is an easier way of > > doing this ? > > > > > I wouldn't go for a HTTPS based solution because HTTPS adds a huge > overhead. > Besides, you only need access control and not secure communication, right? > Could a shared-secret approach work for your use-case? You can define a > secret key per core and share it with the application supposed to use that > core. Then you can write a Java Filter placed before SolrDispatchFilter > which can look at the request path and verify access. > that would work equally well i guess and it's simpler to setup. Then again the security level of a shared-secret approach depends mostly on how secret the shared-secret really is, i'll consider that as the trade-off then. Thanks Jorg
