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

Ishan Chattopadhyaya commented on SOLR-9200:
--------------------------------------------

+1 to all the changes, they all look great!

I'm still wondering if we need the internode calls within the Solr cluster to 
use tokens. It seems to me that they do not, as of this patch, even if the user 
calls use delegation tokens. 

Also, it is my belief that end to end requests work fine, even when internode 
requests are involved. However there are no tests for this, afaict; neither for 
kerberos plugin with delegation tokens, nor with delegation tokens. The former 
situation couldn't be tested at the time of writing the kerberos plugin due to 
lack of ticket cache of minikdc, but maybe that limitation doesn't stop us from 
writing tests for the latter. So, even if we don't write such tests here in 
this issue, I think we should write some as a follow up issue, so that we are 
alerted when such support breaks.

Overall, I am okay with us committing the current patch. However, I think I'd 
be more comfortable if internode calls used tokens as well (or even PKI, 
instead of tokens). I would ideally do that here (unless there are some reasons 
for not doing it that I'm missing completely), however we can as well do that 
as a follow up issue, if you think that is a better approach.

Many thanks for your excellent work on this issue, we needed this for Solr for 
long!

> 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
>         Attachments: SOLR-9200.patch, SOLR-9200.patch, SOLR-9200.patch, 
> SOLR-9200.patch, SOLR-9200.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
(v6.3.4#6332)

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

Reply via email to