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:
||Set to true to enable delegation tokens
||Type name of delegation tokens, most likely doesn't need to change
||Lifetime in seconds for which delegation tokens are valid
||Where delegation token information is stored internally; if not "zookeeper" delegation tokens won't work across solr servers
||(chrooted path) + /token
||Zookeeper location where secret provider information is stored
||(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.
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.