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 Amanda Shuman <am...@gmail.com> on 2018/10/22 13:55:15 UTC
Re: Securying ONLY the web interface console
Just a follow-up to say that I never have resolved this issue
satisfactorily.
------
Dr. Amanda Shuman
Post-doc researcher, University of Freiburg, The Maoist Legacy Project
<http://www.maoistlegacy.uni-freiburg.de/>
PhD, University of California, Santa Cruz
http://www.amandashuman.net/
http://www.prchistoryresources.org/
Office: +49 (0) 761 203 4925
On Mon, Jun 18, 2018 at 6:00 PM Amanda Shuman <am...@gmail.com>
wrote:
> Hi Shawn et al,
>
> As a follow-up to this - then how would you solve the issue? I tried to
> use the instructions to set up basic authentication in solr (per a Stack
> Overflow post) and it worked to secure things, but the web app couldn't
> access solr. Tampering with the app code - which is the solr plug-in used
> for Omeka (https://github.com/scholarslab/SolrSearch) - would require a
> lot of extra work, so I'm wondering if there's a simpler solution. One of
> the developers on that told me to do a reverse proxy like the second poster
> on this chain more or less suggests. But from what I understand of what you
> wrote, this is not ideal because it only protects the admin UI panel and
> not everything else. So how then should I secure everything with the
> exception of calls coming from this web app?
>
> Best,
> Amanda
>
>
> ------
> Dr. Amanda Shuman
> Post-doc researcher, University of Freiburg, The Maoist Legacy Project
> <http://www.maoistlegacy.uni-freiburg.de/>
> PhD, University of California, Santa Cruz
> http://www.amandashuman.net/
> http://www.prchistoryresources.org/
> Office: +49 (0) 761 203 4925
>
>
> On Mon, Mar 19, 2018 at 11:03 PM, Shawn Heisey <ap...@elyograg.org>
> wrote:
>
>> On 3/19/2018 11:19 AM, Jesus Olivan wrote:
>> > i'm trying to password protect only Solr web interface (not queries
>> > launched from my app). I'm currently using SolrCloud 6.6.0 with external
>> > zookeepers. I've read tons of Docs about it, but i couldn't find a
>> proper
>> > way to secure ONLY the web admin console. Can anybody give me some light
>> > about it, please? =)
>>
>> When you add authentication, it's not actually the admin UI that needs
>> authentication. It's all the API requests (queries and the like) that
>> the admin UI makes which require authentication.
>>
>> The admin UI itself is completely static HTML, CSS, Javascript, and
>> images -- it doesn't have ANY information about your installation.
>> Requiring authentication for that doesn't make any sense at all --
>> there's nothing sensitive in those files.
>>
>> When you access the admin UI, the UI pieces are downloaded to your
>> browser, and then the UI actually runs in your browser, accessing the
>> API endpoints. When the UI running in your browser first accesses one
>> of those endpoints, you get the authentication prompt.
>>
>> If we only secured the admin UI and not the API, then somebody who has
>> direct access to your Solr server could do whatever they wanted. The
>> admin UI is just a convenience. Everything it does can be done directly.
>>
>> Thanks,
>> Shawn
>>
>>
>
Re: Securying ONLY the web interface console
Posted by Amanda Shuman <am...@gmail.com>.
Thanks - but I think I'm past those steps now. I set up an nginx reverse
proxy through the plesk panel initially, so that is fine. Binding it to
port 8983 seems to be the issue. Anyways, I think I'll try out the
instructions listed here and cross my fingers..:
https://talk.plesk.com/threads/unable-to-forward-requests-from-nginx-apache.347141/
Amanda
------
Dr. Amanda Shuman
Post-doc researcher, University of Freiburg, The Maoist Legacy Project
<http://www.maoistlegacy.uni-freiburg.de/>
PhD, University of California, Santa Cruz
http://www.amandashuman.net/
http://www.prchistoryresources.org/
Office: +49 (0) 761 203 4925
On Mon, Oct 22, 2018 at 5:35 PM Davis, Daniel (NIH/NLM) [C] <
daniel.davis@nih.gov> wrote:
> I think that it is not really Solr's job to solve this. I'm sure that
> there are many Java ways to solve this with Jetty configuration of JAAS,
> but the *safest* ways involve ports and rights. In other words, port 8983
> and zookeeper ports are then for Solr nodes to communicate with each
> other. But a web proxy on some other port (443 with https suggested)
> forwards /solr to port 8983.
>
> You can use many, many servers as the proxy server - Apache httpd and
> NGINX probably being the biggest contenders. Because my systems team
> understands Apache httpd better, I use the following Apache httpd
> configuration file (this is actually the template version so I don't share
> more):
>
> CASLoginURL https://{{httpd.cas.server}}/cas/login
> CASValidateURL https://{{httpd.cas.server}}/cas/serviceValidate
> CASRootProxiedAs https://{{httpd.local.name}}
> CASCookiePath /var/cache/mod_auth_cas/
>
> RewriteEngine On
> RewriteLogLevel 0
> RewriteRule ^/$ https://%{HTTP_HOST}/solr/ [R=301,L]
>
> <Location /solr>
> ProxyPass http://127.0.0.1:8983/solr retry=0
> ProxyPassReverse http://127.0.0.1:8983/solr
> AuthName "NLM Login"
> AuthType CAS
> CASScope /
> CASAuthNHeader REMOTE_USER
>
> Require user {{solr.admin.users}}
> </Location
>
> Now the Apache httpd directives for CAS are all part of the mod_auth_cas
> module, https://github.com/apereo/mod_auth_cas
>
> Other folks are using OAuth, SAML, or just basic htpasswd protection.
>
> Since you are a PhD candidate, I want to point you towards like Apache the
> definitive guide, rather than towards google which will help you from here
> anyway if you look for "Apache httpd web proxy tutorial' or "NGINX web
> proxy tutorial". Anyway, here are the full docs for Apache httpd and
> links to the book I mention:
>
> * http://httpd.apache.org/docs/2.4/
> *
> https://www.amazon.com/Apache-Definitive-Guide-Ben-Laurie/dp/0596002033/ref=sr_1_1
> *
> https://www.safaribooksonline.com/library/view/apache-the-definitive/0596002033/
>
> > -----Original Message-----
> > From: Amanda Shuman <am...@gmail.com>
> > Sent: Monday, October 22, 2018 9:55 AM
> > To: solr-user@lucene.apache.org
> > Subject: Re: Securying ONLY the web interface console
> >
> > Just a follow-up to say that I never have resolved this issue
> > satisfactorily.
> >
> > ------
> > Dr. Amanda Shuman
> > Post-doc researcher, University of Freiburg, The Maoist Legacy Project
> > <http://www.maoistlegacy.uni-freiburg.de/>
> > PhD, University of California, Santa Cruz
> > http://www.amandashuman.net/
> > http://www.prchistoryresources.org/
> > Office: +49 (0) 761 203 4925
> >
> >
> >
> > On Mon, Jun 18, 2018 at 6:00 PM Amanda Shuman
> > <am...@gmail.com>
> > wrote:
> >
> > > Hi Shawn et al,
> > >
> > > As a follow-up to this - then how would you solve the issue? I tried to
> > > use the instructions to set up basic authentication in solr (per a
> Stack
> > > Overflow post) and it worked to secure things, but the web app couldn't
> > > access solr. Tampering with the app code - which is the solr plug-in
> used
> > > for Omeka (https://github.com/scholarslab/SolrSearch) - would require
> a
> > > lot of extra work, so I'm wondering if there's a simpler solution. One
> of
> > > the developers on that told me to do a reverse proxy like the second
> > poster
> > > on this chain more or less suggests. But from what I understand of what
> > you
> > > wrote, this is not ideal because it only protects the admin UI panel
> and
> > > not everything else. So how then should I secure everything with the
> > > exception of calls coming from this web app?
> > >
> > > Best,
> > > Amanda
> > >
> > >
> > > ------
> > > Dr. Amanda Shuman
> > > Post-doc researcher, University of Freiburg, The Maoist Legacy Project
> > > <http://www.maoistlegacy.uni-freiburg.de/>
> > > PhD, University of California, Santa Cruz
> > > http://www.amandashuman.net/
> > > http://www.prchistoryresources.org/
> > > Office: +49 (0) 761 203 4925
> > >
> > >
> > > On Mon, Mar 19, 2018 at 11:03 PM, Shawn Heisey <ap...@elyograg.org>
> > > wrote:
> > >
> > >> On 3/19/2018 11:19 AM, Jesus Olivan wrote:
> > >> > i'm trying to password protect only Solr web interface (not queries
> > >> > launched from my app). I'm currently using SolrCloud 6.6.0 with
> external
> > >> > zookeepers. I've read tons of Docs about it, but i couldn't find a
> > >> proper
> > >> > way to secure ONLY the web admin console. Can anybody give me some
> > light
> > >> > about it, please? =)
> > >>
> > >> When you add authentication, it's not actually the admin UI that needs
> > >> authentication. It's all the API requests (queries and the like) that
> > >> the admin UI makes which require authentication.
> > >>
> > >> The admin UI itself is completely static HTML, CSS, Javascript, and
> > >> images -- it doesn't have ANY information about your installation.
> > >> Requiring authentication for that doesn't make any sense at all --
> > >> there's nothing sensitive in those files.
> > >>
> > >> When you access the admin UI, the UI pieces are downloaded to your
> > >> browser, and then the UI actually runs in your browser, accessing the
> > >> API endpoints. When the UI running in your browser first accesses one
> > >> of those endpoints, you get the authentication prompt.
> > >>
> > >> If we only secured the admin UI and not the API, then somebody who has
> > >> direct access to your Solr server could do whatever they wanted. The
> > >> admin UI is just a convenience. Everything it does can be done
> directly.
> > >>
> > >> Thanks,
> > >> Shawn
> > >>
> > >>
> > >
>
RE: Securying ONLY the web interface console
Posted by "Davis, Daniel (NIH/NLM) [C]" <da...@nih.gov>.
I think that it is not really Solr's job to solve this. I'm sure that there are many Java ways to solve this with Jetty configuration of JAAS, but the *safest* ways involve ports and rights. In other words, port 8983 and zookeeper ports are then for Solr nodes to communicate with each other. But a web proxy on some other port (443 with https suggested) forwards /solr to port 8983.
You can use many, many servers as the proxy server - Apache httpd and NGINX probably being the biggest contenders. Because my systems team understands Apache httpd better, I use the following Apache httpd configuration file (this is actually the template version so I don't share more):
CASLoginURL https://{{httpd.cas.server}}/cas/login
CASValidateURL https://{{httpd.cas.server}}/cas/serviceValidate
CASRootProxiedAs https://{{httpd.local.name}}
CASCookiePath /var/cache/mod_auth_cas/
RewriteEngine On
RewriteLogLevel 0
RewriteRule ^/$ https://%{HTTP_HOST}/solr/ [R=301,L]
<Location /solr>
ProxyPass http://127.0.0.1:8983/solr retry=0
ProxyPassReverse http://127.0.0.1:8983/solr
AuthName "NLM Login"
AuthType CAS
CASScope /
CASAuthNHeader REMOTE_USER
Require user {{solr.admin.users}}
</Location
Now the Apache httpd directives for CAS are all part of the mod_auth_cas module, https://github.com/apereo/mod_auth_cas
Other folks are using OAuth, SAML, or just basic htpasswd protection.
Since you are a PhD candidate, I want to point you towards like Apache the definitive guide, rather than towards google which will help you from here anyway if you look for "Apache httpd web proxy tutorial' or "NGINX web proxy tutorial". Anyway, here are the full docs for Apache httpd and links to the book I mention:
* http://httpd.apache.org/docs/2.4/
* https://www.amazon.com/Apache-Definitive-Guide-Ben-Laurie/dp/0596002033/ref=sr_1_1
* https://www.safaribooksonline.com/library/view/apache-the-definitive/0596002033/
> -----Original Message-----
> From: Amanda Shuman <am...@gmail.com>
> Sent: Monday, October 22, 2018 9:55 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Securying ONLY the web interface console
>
> Just a follow-up to say that I never have resolved this issue
> satisfactorily.
>
> ------
> Dr. Amanda Shuman
> Post-doc researcher, University of Freiburg, The Maoist Legacy Project
> <http://www.maoistlegacy.uni-freiburg.de/>
> PhD, University of California, Santa Cruz
> http://www.amandashuman.net/
> http://www.prchistoryresources.org/
> Office: +49 (0) 761 203 4925
>
>
>
> On Mon, Jun 18, 2018 at 6:00 PM Amanda Shuman
> <am...@gmail.com>
> wrote:
>
> > Hi Shawn et al,
> >
> > As a follow-up to this - then how would you solve the issue? I tried to
> > use the instructions to set up basic authentication in solr (per a Stack
> > Overflow post) and it worked to secure things, but the web app couldn't
> > access solr. Tampering with the app code - which is the solr plug-in used
> > for Omeka (https://github.com/scholarslab/SolrSearch) - would require a
> > lot of extra work, so I'm wondering if there's a simpler solution. One of
> > the developers on that told me to do a reverse proxy like the second
> poster
> > on this chain more or less suggests. But from what I understand of what
> you
> > wrote, this is not ideal because it only protects the admin UI panel and
> > not everything else. So how then should I secure everything with the
> > exception of calls coming from this web app?
> >
> > Best,
> > Amanda
> >
> >
> > ------
> > Dr. Amanda Shuman
> > Post-doc researcher, University of Freiburg, The Maoist Legacy Project
> > <http://www.maoistlegacy.uni-freiburg.de/>
> > PhD, University of California, Santa Cruz
> > http://www.amandashuman.net/
> > http://www.prchistoryresources.org/
> > Office: +49 (0) 761 203 4925
> >
> >
> > On Mon, Mar 19, 2018 at 11:03 PM, Shawn Heisey <ap...@elyograg.org>
> > wrote:
> >
> >> On 3/19/2018 11:19 AM, Jesus Olivan wrote:
> >> > i'm trying to password protect only Solr web interface (not queries
> >> > launched from my app). I'm currently using SolrCloud 6.6.0 with external
> >> > zookeepers. I've read tons of Docs about it, but i couldn't find a
> >> proper
> >> > way to secure ONLY the web admin console. Can anybody give me some
> light
> >> > about it, please? =)
> >>
> >> When you add authentication, it's not actually the admin UI that needs
> >> authentication. It's all the API requests (queries and the like) that
> >> the admin UI makes which require authentication.
> >>
> >> The admin UI itself is completely static HTML, CSS, Javascript, and
> >> images -- it doesn't have ANY information about your installation.
> >> Requiring authentication for that doesn't make any sense at all --
> >> there's nothing sensitive in those files.
> >>
> >> When you access the admin UI, the UI pieces are downloaded to your
> >> browser, and then the UI actually runs in your browser, accessing the
> >> API endpoints. When the UI running in your browser first accesses one
> >> of those endpoints, you get the authentication prompt.
> >>
> >> If we only secured the admin UI and not the API, then somebody who has
> >> direct access to your Solr server could do whatever they wanted. The
> >> admin UI is just a convenience. Everything it does can be done directly.
> >>
> >> Thanks,
> >> Shawn
> >>
> >>
> >