[
https://issues.apache.org/jira/browse/HADOOP-14920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194064#comment-16194064
]
Xiao Chen commented on HADOOP-14920:
------------------------------------
httpfs tests from HDFS-12600 passed, and the failures there for hdfs looks
unrelated.
Can we add coverage in {{TestDelegationTokenAuthenticationHandlerWithMocks}},
to test renew and cancel of tokens that were gotten with a service? +1 after
that's done
> KMSClientProvider won't work with KMS delegation token retrieved from
> non-Java client.
> --------------------------------------------------------------------------------------
>
> Key: HADOOP-14920
> URL: https://issues.apache.org/jira/browse/HADOOP-14920
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Xiaoyu Yao
> Assignee: Xiaoyu Yao
> Attachments: HADOOP-14920.001.patch, HADOOP-14920.002.patch
>
>
> HADOOP-13381 added support to use KMS delegation token to connect to KMS
> server for key operations. However, the logic to check if the UGI container
> KMS delegation token assumes that the token must contain a service attribute.
> Otherwise, a KMS delegation token won't be recognized.
> For delegation token obtained via non-java client such curl (http), the
> default DelegationTokenAuthenticationHandler only support *renewer* parameter
> and assume the client itself will add the service attribute. This makes a
> java client with KMSClientProvdier can't use for KMS delegation token
> retrieved form non-java client because the token does not contain a service
> attribute.
> I did some investigation on this and found two solutions:
> 1. Similar use case exists for webhdfs, and webhdfs supports it with a
> ["service"
> parameter|https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-hdfs/WebHDFS.html#Get_Delegation_Token].
> We can do this similarly by allowing client to specify a service attribute in
> the request URL and included in the token returned like webhdfs. Even though
> this will change in DelegationTokenAuthenticationHandler and may affect many
> other web component, this seems to be a clean and low risk solution because
> it will be an optional parameter. Also, other components get non-java client
> interop support for free if they have the similar use case.
> 2. The other way to solve this is to release the token check in
> KMSClientProvider to check only the token kind instead of the service. This
> is an easy work around but seems less optimal to me.
> cc: [~xiaochen] for additional input.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
