multicore setup and security

[Jorg Heymans <jo...@gmail.com>]

Hi,

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 ?

Thanks,
Jorg

Re: multicore setup and security

[Jorg Heymans <jo...@gmail.com>]

On Tue, Feb 23, 2010 at 10:09 AM, Shalin Shekhar Mangar <
shalinmangar@gmail.com> wrote:

> On Mon, Feb 22, 2010 at 5:43 PM, Jorg Heymans <jorg.heymans@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

Re: multicore setup and security

[Shalin Shekhar Mangar <sh...@gmail.com>]

On Mon, Feb 22, 2010 at 5:43 PM, Jorg Heymans <jo...@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.

-- 
Regards,
Shalin Shekhar Mangar.