lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ishan Chattopadhyaya (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-7274) Pluggable authentication module in Solr
Date Mon, 13 Apr 2015 16:01:13 GMT

    [ https://issues.apache.org/jira/browse/SOLR-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492547#comment-14492547
] 

Ishan Chattopadhyaya edited comment on SOLR-7274 at 4/13/15 4:00 PM:
---------------------------------------------------------------------

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 questions or 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


was (Author: ichattopadhyaya):
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message