[
https://issues.apache.org/jira/browse/SOLR-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15366913#comment-15366913
]
Gregory Chanan commented on SOLR-9200:
--------------------------------------
Functionality:
1) This patch allows configuration of delegation tokens for the KerberosPlugin.
Existing
configurations will not change and will not support delegation tokens.
The configuration parameters are as follows:
||Key||Type||Default||Description||
|solr.kerberos.delegation.token.enabled|boolean|false|Set to true to enable
delegation tokens
|solr.kerberos.delegation.token.kind|String|solr-dt|Type name of delegation
tokens, most likely doesn't need to change
|solr.kerberos.delegation.token.validity|integer|36000|Lifetime in seconds for
which delegation tokens are valid|
|solr.kerberos.delegation.token.signer.secret.provider|String|zookeeper|Where
delegation token information is stored internally; if not "zookeeper"
delegation tokens won't work across solr servers
|solr.kerberos.delegation.token.signer.secret.provider.zookeper.path|String|(chrooted
path) + /token|Zookeeper location where secret provider information is stored
|solr.kerberos.delegation.token.secret.manager.znode.working.path|String|(chrooted
path) + /zkdtsm|Zookeeper location where token information is stored
2) Includes solrj support for delegation tokens as follows:
a) DelegationTokenRequest/DelegationTokenResponse can be used to
get/cancel/renew delegation tokens
b) HttpSolrClient.Builder now includes a "withDelegationToken" function for
creating an HttpSolrClient
that uses a delegation token to authenticate
Note that hadoop's delegation token responses are in json map format, so
there is a new ResponseParser
for that in DelegationTokenResponse; I couldn't find an existing response
parser that worked
Issues / Workarounds:
3) AuthenticationPlugin has an incompatible change that means this should only
go into the next major version.
Basically:
{code}void doAuthenticate{code}
changed to:
{code}boolean doAuthenticate{code}
This is to support cases where authentication succeeds, but solr itself
shouldn't process the request; e.g.
in the delegation token management operations (get, cancel, renew). The
boolean, if false, indicates a short
circuit out of the rest of the solr dispatch logic.
4) DelegationTokenKerberosFilter includes a workaround for null query strings.
The versions of
hadoop / httpclient that we use don't work with null HttpServletRequest query
strings, which the jetty
version we use can provide. This can be solved by using HTTPCLIENT-1746 (not
released yet) or HADOOP-12767
(not released in a stable version).
5) hadoop's delegation token code writes to a closed PrintWriter; this doesn't
seem to be a problem for the
version of jetty that hadoop uses, but it causes an issue with our version. I
filed HADOOP-13346 to fix that,
until then, I wrote a PrintWriterWrapper that ignores closes.
6) The hadoop zookeeper delegation token code uses Curator rather than
SolrZkClient; the conversion
from SolrZkClient is messy in a few places:
a) We use the ZkController.ZkClient's ACL Provider for the delegation tokens
in ZK, but it's not obvious this
is what you'd actually want to use. For example, it may be reasonable to
have most solr znodes be readable
(because clients read e.g. clusterstate.json), but you probably don't want
the delegation token information
to be readable by anyone outside "solr". I haven't checked recently, but I
don't think we provide any
built in ACLProviders that would do something reasonable here in the
general case. Basically, it's easy to
get this wrong and leak security information.
b) Getting credentials information to curator also isn't great. Again, we
use ZkController.ZkClient's credentials
(at AuthenticationPlugin.init) time, but given the
"setZkCredentialsToAddAutomatically" function, these could
in theory change. I haven't looked into changing that into a builder so
it's guaranteed not to change.
c) Retrying logic is handled completely differently. In theory, you'd like
the curator logic to follow ZkController.ZkClient's
ZkClientConnectionStrategy logic, but it's not clear how to implement
this. Instead, we just use curator's ExponentialBackoffRetry.
> 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-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
