[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14241254#comment-14241254
]
Per Steffensen commented on SOLR-6625:
--------------------------------------
bq. Maybe Per Steffensen 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.
* Every paranoid customers. In general we/they just do not want a user to be
able to indirectly (through distributed sub-requests) get a response to a query
he is not allowed to fire directly. There is a lot of details to it that I will
spare you, but overall we are also 1) using authorization to prevent specific
groups of users to do queries (directly or indirectly) that takes certain
amounts of resources from the system or 2) to fetch certain fields or any
information that can be derived from those fields. Ad 1) By a lot of testing we
know which types of queries really takes a lot of resources out of our system,
but it is hard to be sure that a query that does not seem to be such a query,
does not indirectly fire such queries in distributed sub-requests. Ad 2) Just
because an outer request does not specifically ask for a certain field, it is
hard to know that the indirect sub-request also does not, even though in
practice it is so (except for id an score)
* Distributed audit logging
* Etc.
I realize that the reasons we want the credentials from the outer request
forwarded in sub-requests are very thin. I understand if this is not something
that you feel is necessary to support in Apache Solr. But if it does not make
the solution much more complicated you might just support it. I do not think
SOLR-4470 is a complicated solution - most of it, really, is testing.
bq. Likewise you can see all of the various other authentication schemes
HttpClient supports (SPNego included)
SOLR-4470 does not try to do itself what HttpClient can already do. The
HttpClient capabilities can just be used outside or through the
authentication-framework introduced in SOLR-4470. SOLR-4470 is mostly about
joggling the credentials inside Solr-nodes. When they have to be added to
requests, of course use HttpClient capabilities.
bq. To get around this, we use secure impersonation
Interesting!
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
