Ishan Chattopadhyaya commented on SOLR-9200:

Maybe I'm misunderstanding something, but don't the internode calls already use 
PKI – that seems to always be used for internode calls with SolrCloud. I don't 
see what's different with this patch than before it.

Internode calls use PKI authentication for any plugin that does not implement 
{{HttpClientInterceptorPlugin}}. Kerberos plugin uses that "interceptor" and 
hence deals with its own internode communication (each node has a client 
principal associated with it, specified in a jaas config file, for making 
internode calls). I think the committed patch here for delegation tokens does 
not have the internode communications using the delegation tokens. If that is 
the case, we can open another issue to add a test and fix.

> Add Delegation Token Support to Solr
> ------------------------------------
>                 Key: SOLR-9200
>                 URL: https://issues.apache.org/jira/browse/SOLR-9200
>             Project: Solr
>          Issue Type: New Feature
>          Components: security
>            Reporter: Gregory Chanan
>            Assignee: Gregory Chanan
>             Fix For: 6.2, master (7.0)
>         Attachments: SOLR-9200.patch, SOLR-9200.patch, SOLR-9200.patch, 
> SOLR-9200.patch, SOLR-9200.patch, SOLR-9200_branch_6x.patch, 
> SOLR-9200_branch_6x.patch, SOLR-9200_branch_6x.patch
> SOLR-7468 added support for kerberos authentication via the hadoop 
> authentication filter.  Hadoop also has support for an authentication filter 
> that supports delegation tokens, which allow authenticated users the ability 
> to grab/renew/delete a token that can be used to bypass the normal 
> authentication path for a time.  This is useful in a variety of use cases:
> 1) distributed clients (e.g. MapReduce) where each client may not have access 
> to the user's kerberos credentials.  Instead, the job runner can grab a 
> delegation token and use that during task execution.
> 2) If the load on the kerberos server is too high, delegation tokens can 
> avoid hitting the kerberos server after the first request
> 3) If requests/permissions need to be delegated to another user: the more 
> privileged user can request a delegation token that can be passed to the less 
> privileged user.
> Note to self:
> In 
> https://issues.apache.org/jira/browse/SOLR-7468?focusedCommentId=14579636&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579636
>  I made the following comment which I need to investigate further, since I 
> don't know if anything changed in this area:
> {quote}3) I'm a little concerned with the "NoContext" code in KerberosPlugin 
> moving forward (I understand this is more a generic auth question than 
> kerberos specific). For example, in the latest version of the filter we are 
> using at Cloudera, we play around with the ServletContext in order to pass 
> information around 
> (https://github.com/cloudera/lucene-solr/blob/cdh5-4.10.3_5.4.2/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L106).
>  Is there any way we can get the actual ServletContext in a plugin?{quote}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to