lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cassandra Targett (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-9200) Add Delegation Token Support to Solr
Date Thu, 01 Sep 2016 19:32:20 GMT

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

Cassandra Targett commented on SOLR-9200:
-----------------------------------------

[~gchanan] or [~ichattopadhyaya] - is the functionality described in this earlier comment
https://issues.apache.org/jira/browse/SOLR-9200?focusedCommentId=15366913&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15366913
still accurate? This has not yet been added to the Solr Ref Guide, and since I think there
is some interest for it, we should try to get it in while we're waiting for the issue with
publishing 6.2 to be resolved.

It belongs with the Kerberos documentation at https://cwiki.apache.org/confluence/display/solr/Kerberos+Authentication+Plugin,
correct?

> 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
(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