You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Gregory Chanan (JIRA)" <ji...@apache.org> on 2016/07/28 19:11:20 UTC
[jira] [Comment Edited] (SOLR-9200) Add Delegation Token Support to
Solr
[ https://issues.apache.org/jira/browse/SOLR-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15398043#comment-15398043 ]
Gregory Chanan edited comment on SOLR-9200 at 7/28/16 7:10 PM:
---------------------------------------------------------------
Thanks for taking a look, [~ichattopadhyaya]
bq. 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.
I don't think they do, this is just for client authentication
{quote}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.{quote}
Sure, SOLR-9324 contains such a test. Although it doesn't really solve the minikdc problem, that just uses a different authentication mechanism.
{quote}
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.
{quote}
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.
was (Author: gchanan):
Thanks for taking a look, [~ichattopadhyaya]
bq. 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.
I don't think they do, this is just for client authentication
{quote}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.{quote}
Sure, SOLR-9324 contains such a test. Although it doesn't really solve the minikdc problem, that just uses a different authentication mechanism.
{code}
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.
{code}
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.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org