[
https://issues.apache.org/jira/browse/SOLR-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492547#comment-14492547
]
Ishan Chattopadhyaya commented on SOLR-7274:
--------------------------------------------
bq. Some initial thoughts...
[~gchanan], thanks a lot for your review!
{quote}
- try (SolrClient client = new HttpSolrClient(url, httpClient)) {
+ try (SolrClient client = new HttpSolrClient(url)) {
Why this change?
{quote}
I couldn't think of a way to configure the httpclient used by the
HttpShardHandler for inter node communication. This was because by the time the
plugin's init() did a HttpClientUtils.setConfigurer() with the plugin's
httpclient configurer, the default httpclient used by the HttpShardHandler and
its factory was already configured by the stock HttpClientConfigurer. So, *to
go ahead with the rest of my testing*, I made had used this hack, which in
effect created a new httpclient for every request (and thus used the plugin's
configurer).
Now, I've fixed this ^1^ by adding a reconfigureHttpClient() method for the
ShardHandlerFactory.
bq. 2. Can we comment on the AuthenticationLayerPlugin? I don't think it's
obvious what needs to be implemented
I've added some javadocs ^1^.
{noformat}
public interface AuthenticationLayerPlugin {
/**
* This is called upon loading up of a plugin, used for setting it up.
* @param filterConfig used for any configs passed in from the servlet filter
* config, or for access to the servlet context.
* @param zkController the zk controller
*/
public void init(FilterConfig filterConfig, ZkController zkController);
/**
* This method must authenticate the request. Upon a successful
authentication, this
* must call the next filter in the filter chain and set the user principal
of the request,
* or else, upon an error or an authentication failure, throw an exception.
*
* @param request the http request
* @param response the http response
* @param filterChain the servlet filter chain
* @throws Exception any exception thrown during the authentication, e.g.
* PriviledgedAccessException
*/
public void doAuthenticate(ServletRequest request, ServletResponse response,
FilterChain filterChain) throws Exception;
/**
*
* @return Returns an instance of a HttpClientConfigurer to be used for
configuring the
* httpclients for use during internode communication.
*/
public HttpClientConfigurer getDefaultConfigurer();
}
{noformat}
Do you think it is clearer now? Also, do you have any suggestions for a change
to the interface?
{quote}
3. params.put("token.valid", System.getProperty("kerberos.name.rules", "30"));
This doesn't look correct
{quote}
Oops, fixed ^1^. Over zealous copy-pasting.
{quote}
5. In HttpSolrClient.java: "postOrPut.setEntity(new
BufferedHttpEntity(postOrPut.getEntity()));"
...
we set up a client configurer that is smart enough to handle the http requests
for that authentication scheme
{quote}
Thanks for the pointer! I had put it in there, thinking of ways to fix it in a
subsequent patch. The HttpRequestInterceptor seems like a much cleaner way than
I had initially planned for. I've updated the patch to reflect this ^1^.
{quote}
6. This doesn't seem to handle forwarding requests in the SolrDispatchFilter.
...
I don't know how to solve that without implementing SOLR-6625, though.
{quote}
After the change to add a reconfigureHttpClient() to ShardHandlerFactory ^1^,
the SolrDispatchFilter's remoteQuery() now works. Do you see any problem with
that in the patch ^1^ / have I missed something?
{quote}
4. ....
Using "SolrClient" instead of whatever zookeeper uses (default "Client", see
the code I linked above) for the jaas configuration app name will cause you to
have to deal with two issues.
{quote}
The reason why I went with a different app name for ZK and solr clients in the
patch was that in my dev testing environment, zk wasn't kerberized, and hence I
wanted to use plain unsecured connection to zk, while using kerberos based
authc for Solr. I don't know how users actually setup their deployments of ZK
and Solr, so I am looking for suggestions on how to go about it. I wasn't aware
of the side effect of refreshing of tickets, so that seems like a great
benefit. Do you think the plugin should should support both (1. same jaas
configs for zk & solr clients, and 2. different jaas configs for zk and solr
clients), configureably? Of course, that would involve code for refreshing
credentials, but maybe some generic hooks for this in an "pluggable
authentication framework" might be handy anyway?
[1] I'll add the patch shortly
> Pluggable authentication module in Solr
> ---------------------------------------
>
> Key: SOLR-7274
> URL: https://issues.apache.org/jira/browse/SOLR-7274
> Project: Solr
> Issue Type: Sub-task
> Reporter: Anshum Gupta
> Attachments: SOLR-7274.patch
>
>
> It would be good to have Solr support different authentication protocols.
> To begin with, it'd be good to have support for kerberos and basic auth.
--
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
