Securying ONLY the web interface console

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Securying ONLY the web interface console

Jesus Olivan
hi!

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? =)

Thanks in advance!
Reply | Threaded
Open this post in threaded view
|

Re: Securying ONLY the web interface console

Rahul Singh-3
Use a proxy server that only gives access to the update / select handlers (URLs). Can do it with a numerous programming languages or with a simple proxy in nginx.

The whole web server running SolR is not supposed to be out in the open. You are opening yourself up to too many issues.

--
Rahul Singh
[hidden email]

Anant Corporation

On Mar 19, 2018, 12:19 PM -0500, Jesus Olivan <[hidden email]>, wrote:
> hi!
>
> 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? =)
>
> Thanks in advance!
Reply | Threaded
Open this post in threaded view
|

Re: Securying ONLY the web interface console

Shawn Heisey-2
In reply to this post by Jesus Olivan
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

Reply | Threaded
Open this post in threaded view
|

Re: Securying ONLY the web interface console

Amanda Shuman
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 <[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Securying ONLY the web interface console

Amanda Shuman
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 <[hidden email]>
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 <[hidden email]>
> 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
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

RE: Securying ONLY the web interface console

Davis, Daniel (NIH/NLM) [C]
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 ^/$ <a href="https://%">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 <[hidden email]>
> Sent: Monday, October 22, 2018 9:55 AM
> To: [hidden email]
> 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
> <[hidden email]>
> 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 <[hidden email]>
> > 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
> >>
> >>
> >
Reply | Threaded
Open this post in threaded view
|

Re: Securying ONLY the web interface console

Amanda Shuman
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] <
[hidden email]> 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 ^/$ <a href="https://%">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 <[hidden email]>
> > Sent: Monday, October 22, 2018 9:55 AM
> > To: [hidden email]
> > 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
> > <[hidden email]>
> > 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 <[hidden email]>
> > > 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
> > >>
> > >>
> > >
>