[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14239957#comment-14239957
]
Gregory Chanan commented on SOLR-6625:
--------------------------------------
bq. This would seem to do the trick, except for perhaps propagating the
authentication from the original request though this shouldn't really be a
requirement since the challenge will be static in the web container that you
can live with having static credentials in the solr distrib - if it changes
deploy new config changes.
Right, as far as I understand it, that part is there to propagate the
authentication from the original request. Maybe [~steff1193] can chime in with
the motivation there rather than always using the static credentials -- I'm
guessing it is because there is some organization-specific authorization
checking expecting the actual user who made the original request.
This patch is based on what we do with Apache Sentry and is a little different
than the SOLR-4470 approach, I'll explain that below. I put the SolrRequest
param in the callback because it was easy, we have evidence that other people
who implemented authentication find it useful to have access to the
SolrRequest, and it is compatible with SOLR-4470.
bq. Likewise you can see all of the various other authentication schemes
HttpClient supports (SPNego included)
Yep, we are actually using HttpClient's SPNego support -- I plan on
contributing that in separate patch. One difference is Solr doesn't use
repeatable requests, so we need to address that in some way (e.g. use
BufferedEntity like SOLR-4470). That part seems like it could be implemented
either via this HttpClientRequestCallback or an HttpRequestInterceptor.
bq. Are you using these credentials to execute distributed requests? Or would
it make sense to have a certain user hit the frontend shard, then that shard
will perform the distributed request on behalf of the system's authentication
credentials?
The later is close to correct. In Sentry we have some request handlers that do
the checking based on the authenticated user, so if you make a request to a
shard and the request is not forwarded, everything works as expected. All
solr-to-solr requests are done via internal (solr) credentials; we may have
used SOLR-4470 if it were available in the version we were developing against
and it was tested with SPNego, but it wasn't and this approach is simpler. So
this means in the forwarded case, the request looks like it came from solr and
thus you can't do proper authorization. To get around this, we use secure
impersonation (http://hadoop.apache.org/docs/r1.2.1/Secure_Impersonation.html)
to make the forwarded request look like it came from the original authenticated
user. That's what the part about including the context from the
SolrQueryRequest is about above.
Now, you could argue that these concerns should be separated -- i.e. there
should be some sort of forwarded request callback for handling the
authenticated user for that specific case and the HttpRequestInterceptor should
handle the http concerns around BufferedEntities and such. I'm not totally
against that, but I'd say that the HttpClientRequestCallback is compatible with
two independently developed authentication/authorization implementations
(Sentry and SOLR-4470), and the separated
ForwardedCallback/HttpRequestInterceptor approach doesn't seem simpler. And
you can still use HttpRequestInterceptors if you want to write your own
HttpClientConfigurer.
Hopefully that addresses your questions [~sdavids], any feedback is appreciated.
> HttpClient callback in HttpSolrServer
> -------------------------------------
>
> Key: SOLR-6625
> URL: https://issues.apache.org/jira/browse/SOLR-6625
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: Gregory Chanan
> Assignee: Gregory Chanan
> Priority: Minor
> Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch,
> SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch
>
>
> Some of our setups use Solr in a SPNego/kerberos setup (we've done this by
> adding our own filters to the web.xml). We have an issue in that SPNego
> requires a negotiation step, but some HttpSolrServer requests are not
> repeatable, notably the PUT/POST requests. So, what happens is,
> HttpSolrServer sends the requests, the server responds with a negotiation
> request, and the request fails because the request is not repeatable. We've
> modified our code to send a repeatable request beforehand in these cases.
> It would be nicer if HttpSolrServer provided a pre/post callback when it was
> making an httpclient request. This would allow administrators to make
> changes to the request for authentication purposes, and would allow users to
> make per-request changes to the httpclient calls (i.e. modify httpclient
> requestconfig to modify the timeout on a per-request basis).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
