Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 28 Jul 2016 22:59:20 +0000 (UTC)
From: "Steve Rowe (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12977064.1465433980000.162989.1469746760514@Atlassian.JIRA>
In-Reply-To: <JIRA.12977064.1465433980000@Atlassian.JIRA>
References: <JIRA.12977064.1465433980000@Atlassian.JIRA> <JIRA.12977064.1465433980558@arcas>
Subject: [jira] [Commented] (SOLR-9200) Add Delegation Token Support to Solr
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 28 Jul 2016 22:59:22 -0000


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

Steve Rowe commented on SOLR-9200:
----------------------------------

The commit on this issue is causing the Maven build to fail (from [https://builds.apache.org/job/Lucene-Solr-Maven-master/1814/]):

{noformat}
 [mvn] [ERROR] COMPILATION ERROR : 
      [mvn] [INFO] -------------------------------------------------------------
      [mvn] [ERROR] /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/solr/core/src/test/org/apache/solr/cloud/KerberosTestServices.java:[29,77] package com.carrotsearch.ant.tasks.junit4.dependencies.com.google.common.base does not exist
      [mvn] [ERROR] /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/solr/core/src/test/org/apache/solr/cloud/KerberosTestServices.java:[195,7] cannot find symbol
      [mvn]   symbol:   variable Preconditions
      [mvn]   location: class org.apache.solr.cloud.KerberosTestServices.Builder
      [mvn] [ERROR] /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/solr/core/src/test/org/apache/solr/cloud/KerberosTestServices.java:[196,7] cannot find symbol
      [mvn]   symbol:   variable Preconditions
      [mvn]   location: class org.apache.solr.cloud.KerberosTestServices.Builder
      [mvn] [ERROR] /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/solr/core/src/test/org/apache/solr/cloud/KerberosTestServices.java:[206,7] cannot find symbol
      [mvn]   symbol:   variable Preconditions
      [mvn]   location: class org.apache.solr.cloud.KerberosTestServices.Builder
      [mvn] [ERROR] /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/solr/core/src/test/org/apache/solr/cloud/KerberosTestServices.java:[207,7] cannot find symbol
      [mvn]   symbol:   variable Preconditions
      [mvn]   location: class org.apache.solr.cloud.KerberosTestServices.Builder
      [mvn] [INFO] 5 errors 
{noformat}

This import line in {{KerberosTestServices}} is the source of the problems:

{noformat}
import com.carrotsearch.ant.tasks.junit4.dependencies.com.google.common.base.Preconditions;
{noformat}

I'm guessing the problem is that the junit4 ant tasks aren't on Maven's test classpath.

But why is this Guava class being loaded via this shaded route, when Guava is a direct Solr dependency?  AFAICT all other uses of {{Preconditions}} in Solr use this import instead - I'll test now to see if that makes the Maven build happy:

{noformat}
import com.google.common.base.Preconditions;
{noformat}

> 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