Why is Knox is passing though basic authentication credentials to solr?

[#1]

Hi all,

I'm am trying to configure the ranger-solr-plugin to work with knox authentication in the Sandbox 2.6.0. I'm using Solr 7.1, Knox 0.12.0 and Ranger 0.7 . Kerberos is enabled. The ranger-solr-plugin works fine with a direct connection (kerberos authentication) to solr using a cURL request. When I submit a cURL request I get a 401 "Authentication required" error. The Solr logs show that the credentials passed through by Knox are the basic auth credentials (that were passed to Knox) when Solr is expecting kerberos authentication. Any advice appreciated.

solr logs:

2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel REQUEST for //sandbox.hortonworks.com:8443/solr/techproducts/query?q=* on HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts...=*}
GET //sandbox.hortonworks.com:8443/solr/techproducts/query?q=* HTTP/1.1
X-Forwarded-For: 172.17.0.2
X-Forwarded-Proto: https
X-Forwarded-Port: 8443
X-Forwarded-Host: sandbox.hortonworks.com:8443
X-Forwarded-Server: sandbox.hortonworks.com
X-Forwarded-Context: /gateway/default
Authorization: Basic dG9tOnRvbS1wYXNzd29yZA==
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2^M
Host: sandbox.hortonworks.com:8443
Accept: */*
Connection: keep-alive
Accept-Encoding: gzip,deflate

2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts...=*} onContentComplete
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts...=*} onRequestComplete
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpInput HttpInputOverHTTP@2e0a216d[c=0,q=1,[0]=EOF,s=STREAM] addContent EOF
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpConnection HttpConnection@380a76ec[SelectChannelEndPoint@689b879d{/172.17.0.2:50568<->9041,Open,in,out,-,-,1/12... of -1},g=HttpGenerator@c99a91f{s=START},c=HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*}] parsed true HttpParser{s=END,0 of -1}
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpConnection releaseRequestBuffer HttpConnection@380a76ec[SelectChannelEndPoint@689b879d{/172.17.0.2:50568<->9041,Open,in,out,-,-,1/12... of -1},g=HttpGenerator@c99a91f{s=START},c=HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts/query?q=*}]
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=IDLE,uri=//sandbox.hortonworks.com:8443/solr/techproducts...=*} handle //sandbox.hortonworks.com:8443/solr/techproducts/query?q=*
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannelState HttpChannelState@275bce0{s=IDLE a=NOT_ASYNC i=true r=NONE/false w=false} handling IDLE
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.HttpChannel HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=DISPATCHED,uri=//sandbox.hortonworks.com:8443/solr/techpr...=*} action DISPATCH
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.Server REQUEST GET /solr/techproducts/query on HttpChannelOverHttp@32c7ec9f{r=2,c=false,a=DISPATCHED,uri=//sandbox.hortonworks.com:8443/solr/techpr...=*}
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.h.ContextHandler scope null||/solr/techproducts/query @ o.e.j.w.WebAppContext@7d70d1b1{/solr,file:///opt/solr-7.1.0/server/solr-webapp/webapp/,AVAILABLE}{/o...}
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.h.ContextHandler context=/solr||/techproducts/query @ o.e.j.w.WebAppContext@7d70d1b1{/solr,file:///opt/solr-7.1.0/server/solr-webapp/webapp/,AVAILABLE}{/o...}
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.session sessionManager=org.eclipse.jetty.server.session.HashSessionManager@2a556333
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.session session=null
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.ServletHandler servlet /solr|/techproducts/query|null -> default@5c13d641==org.eclipse.jetty.servlet.DefaultServlet,jsp=null,order=0,inst=true
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.ServletHandler chain=SolrRequestFilter->default@5c13d641==org.eclipse.jetty.servlet.DefaultServlet,jsp=null,order=0,inst=true
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.e.j.s.ServletHandler call filter SolrRequestFilter
2018-01-08 03:39:43.697 DEBUG (qtp42121758-16) [ ] o.a.h.s.a.s.AuthenticationFilter Request [http://sandbox.hortonworks.com:8443/solr/techproducts/query?q=*] triggering authentication
2018-01-08 03:39:43.697 WARN (qtp42121758-16) [ ] o.a.h.s.a.s.KerberosAuthenticationHandler 'Authorization' does not start with 'Negotiate' : Basic dG9tOnRvbS1wYXNzd29yZA==
2018-01-08 03:39:43.698 DEBUG (qtp42121758-16) [ ] o.e.j.s.ErrorPageErrorHandler getErrorPage(GET /solr/techproducts/query) => error_page=null (from global default)

[#2]

This is fixed in at least HDP 2.6.5. I didn't check back farther. The underlying issue was that Knox didn't send the correct headers to Solr. It was passing through the original headers instead of rewriting them. This was fixed for Solr in Knox.