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 Christian Ramseyer <rc...@networkz.ch> on 2013/11/12 13:09:08 UTC
Multi-Tenant Setup in Single Core
Hi guys
I'm prototyping a multi-tenant search. I have various document sources and a tenant can potentially access subsets of any source.
Also tenants have overlapping access to the sources, why I'm trying to do it in a single core.
I'm doing this by labeling the source (origin, single value) and tag the individual documents with a list of clients that can
access it (required_access_token, array). A tenant then gets a Velocity search handler with invariant fq like this:
<requestHandler name="/searchui_client1" class="solr.SearchHandler">
<lst name="invariants"> <str name="fq">
(origin:(client1docs OR generaldocs) AND required_access_token:(client1))
</str></lst>
<requestHandler name="/searchui_client2" class="solr.SearchHandler">
<lst name="invariants"><str name="fq">
(origin:(client2docs OR generaldocs) AND required_access_token:(client2))
</str></lst>
<requestHandler name="/searchui_client3" class="solr.SearchHandler">
<lst name="invariants"><str name="fq">
(origin:(client3docs OR generaldocs) AND required_access_token:(client3))
</str></lst>
Access to the search handler by client is controlled via a reverse proxy, and all the other handlers like /browse or /select
are not available.
Do you guys see any obvious security problems with this? I'm especially worried about some kind of "SQL Injection" into the query field
(edismax parser) in the velocity template handler which would allow to override or add stuff to the invariant fq, or the ability to
select another query handler via URL parameters like /searchui_client1?qt=searchui_client2 or similar.
Do you think this setup can be reasonably safe?
Thanks
Christian
Re: Multi-Tenant Setup in Single Core
Posted by Christian Ramseyer <rc...@networkz.ch>.
On 11/12/13 5:20 PM, Shawn Heisey wrote:
> Ensure that all handler names start with a slash character, so they are
> things like "/query", "/select", and so on. Make sure that handleSelect
> is set to false on your requestDispatcher config. This is how Solr 4.x
> examples are set up already.
>
> With that config, the "qt" parameter will not function and will be
> ignored -- you must use the request handler path as part of the URL --
> /solr/corename/handler.
Great thanks, I already had it this way but I wasn't aware of these fine
details, very helpful.
Christian
Re: Multi-Tenant Setup in Single Core
Posted by Shawn Heisey <so...@elyograg.org>.
On 11/12/2013 6:13 AM, Christian Ramseyer wrote:
> So I'm worried about something that uses these URL paths, say
>
> https://reverse-proxy/mapping-to-solr/searchui_client?qt=update&
> commit=true&stream.body=<delete><query>*:*</query></delete>
Ensure that all handler names start with a slash character, so they are
things like "/query", "/select", and so on. Make sure that handleSelect
is set to false on your requestDispatcher config. This is how Solr 4.x
examples are set up already.
With that config, the "qt" parameter will not function and will be
ignored -- you must use the request handler path as part of the URL --
/solr/corename/handler.
Thanks,
Shawn
Re: Multi-Tenant Setup in Single Core
Posted by Christian Ramseyer <rc...@networkz.ch>.
On 11/12/13 1:51 PM, Erick Erickson wrote:
> When you mention velocity, you're talking about the stock Velocity Response
> Writer that comes with the example? Because if you're exposing the Solr
> http address to the world, accessing each others data is the least of your
> worries. To whit:
>
> http://machine:8983/solr/collection/update?commit=true&stream.body=
> <delete><query>*:*</query></delete>
>
> Often people put a dedicated app in front of their Solr and secure that,
> then put a firewall between their Solr and the world that only lets
> requests through from the known app machines.
Thanks Erick
Yes it is the stock velocity writer. But, this is an intranet app in a
segmented environment. From the client networks, Solr can only be
accessed via an Apache Reverse Proxy, and the only URL paths that can be
accessed are the velocity response handlers at
https://reverse-proxy/mapping-to-solr/searchui_client*
All other paths are blocked at the reverse proxy level.
So I'm worried about something that uses these URL paths, say
https://reverse-proxy/mapping-to-solr/searchui_client?qt=update&
commit=true&stream.body=<delete><query>*:*</query></delete>
to stay with your example.
Christian
>
> Best,
> Erick
>
>
> On Tue, Nov 12, 2013 at 7:09 AM, Christian Ramseyer <rc...@networkz.ch> wrote:
>
>> Hi guys
>>
>> I'm prototyping a multi-tenant search. I have various document sources and
>> a tenant can potentially access subsets of any source.
>> Also tenants have overlapping access to the sources, why I'm trying to do
>> it in a single core.
>>
>> I'm doing this by labeling the source (origin, single value) and tag the
>> individual documents with a list of clients that can
>> access it (required_access_token, array). A tenant then gets a Velocity
>> search handler with invariant fq like this:
>>
>> <requestHandler name="/searchui_client1"
>> class="solr.SearchHandler">
>> <lst name="invariants"> <str name="fq">
>> (origin:(client1docs OR generaldocs) AND
>> required_access_token:(client1))
>> </str></lst>
>>
>> <requestHandler name="/searchui_client2"
>> class="solr.SearchHandler">
>> <lst name="invariants"><str name="fq">
>> (origin:(client2docs OR generaldocs) AND
>> required_access_token:(client2))
>> </str></lst>
>>
>> <requestHandler name="/searchui_client3"
>> class="solr.SearchHandler">
>> <lst name="invariants"><str name="fq">
>> (origin:(client3docs OR generaldocs) AND
>> required_access_token:(client3))
>> </str></lst>
>>
>> Access to the search handler by client is controlled via a reverse proxy,
>> and all the other handlers like /browse or /select
>> are not available.
>>
>> Do you guys see any obvious security problems with this? I'm especially
>> worried about some kind of "SQL Injection" into the query field
>> (edismax parser) in the velocity template handler which would allow to
>> override or add stuff to the invariant fq, or the ability to
>> select another query handler via URL parameters like
>> /searchui_client1?qt=searchui_client2 or similar.
>>
>> Do you think this setup can be reasonably safe?
>>
>> Thanks
>>
>> Christian
>>
>
Re: Multi-Tenant Setup in Single Core
Posted by Erick Erickson <er...@gmail.com>.
When you mention velocity, you're talking about the stock Velocity Response
Writer that comes with the example? Because if you're exposing the Solr
http address to the world, accessing each others data is the least of your
worries. To whit:
http://machine:8983/solr/collection/update?commit=true&stream.body=
<delete><query>*:*</query></delete>
Often people put a dedicated app in front of their Solr and secure that,
then put a firewall between their Solr and the world that only lets
requests through from the known app machines.
Best,
Erick
On Tue, Nov 12, 2013 at 7:09 AM, Christian Ramseyer <rc...@networkz.ch> wrote:
> Hi guys
>
> I'm prototyping a multi-tenant search. I have various document sources and
> a tenant can potentially access subsets of any source.
> Also tenants have overlapping access to the sources, why I'm trying to do
> it in a single core.
>
> I'm doing this by labeling the source (origin, single value) and tag the
> individual documents with a list of clients that can
> access it (required_access_token, array). A tenant then gets a Velocity
> search handler with invariant fq like this:
>
> <requestHandler name="/searchui_client1"
> class="solr.SearchHandler">
> <lst name="invariants"> <str name="fq">
> (origin:(client1docs OR generaldocs) AND
> required_access_token:(client1))
> </str></lst>
>
> <requestHandler name="/searchui_client2"
> class="solr.SearchHandler">
> <lst name="invariants"><str name="fq">
> (origin:(client2docs OR generaldocs) AND
> required_access_token:(client2))
> </str></lst>
>
> <requestHandler name="/searchui_client3"
> class="solr.SearchHandler">
> <lst name="invariants"><str name="fq">
> (origin:(client3docs OR generaldocs) AND
> required_access_token:(client3))
> </str></lst>
>
> Access to the search handler by client is controlled via a reverse proxy,
> and all the other handlers like /browse or /select
> are not available.
>
> Do you guys see any obvious security problems with this? I'm especially
> worried about some kind of "SQL Injection" into the query field
> (edismax parser) in the velocity template handler which would allow to
> override or add stuff to the invariant fq, or the ability to
> select another query handler via URL parameters like
> /searchui_client1?qt=searchui_client2 or similar.
>
> Do you think this setup can be reasonably safe?
>
> Thanks
>
> Christian
>