[
https://issues.apache.org/jira/browse/HDFS-8155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14499092#comment-14499092
]
Jakob Homan commented on HDFS-8155:
-----------------------------------
bq. For the first use case – WebHDFS now recognizes the auth cookie of the UI
therefore the UI works as long as any third-party filter behaves correctly
w.r.t. the UI pages.
I agree. I'm not considering UI right now.
bq. For the second use case – WebHDFS is designed to use DT as the
authentication method.
WebHDFS supports [three distinct types of
authentication|https://hadoop.apache.org/docs/r2.5.1/hadoop-project-dist/hadoop-hdfs/WebHDFS.html#Authentication]:
SPENGO, simple, delegation token.
Please consider JIRA in light of the linked JIRA, HDFS-8154, which is going to
extract WebHDFS as a separate interface that other backing stores will support.
Currently the only way for some backing store to gain access to the Hadoop
ecosystem is to implement oah.FileSystem, which would give it access to JVM
based frameworks (Pig, Hive, Spark, etc.). Additionally, such a store may wish
to expose a REST interface to itself or provide easy access to non-JVM systems.
Such a system could go about defining a REST specification into the
oah.FileSystem, but that definition would look exactly (or pretty much) like
what WebHDFS already defines. Instead of such duplication, HDFS-8154 looks to
make what we already have (WebHDFS) more general and useful. As part of that,
we need to add support for a more widely used authorization system, OAuth2.
An important point is that
[WebHDFS|https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/web/WebHdfsFileSystem.java#L91]
is misnamed:
{code:title=WebHDFSFileSystem.java}
public class WebHdfsFileSystem extends FileSystem
implements DelegationTokenRenewer.Renewable,
TokenAspect.TokenManagementDelegator {
{code}
WebHDFS extends FileSystem, not DistributedFileSystem and so should properly be
called WebFileSystem. As such, the general purpose methods that it implements
(and its REST endpoints expose) are suitable for implementation for lots of
backing stores. HDFS-8154 and this JIRA are about making that extensibility
explicit and easy.
bq. To authenticate, the third-party filter (OAuth2 filter included) should
control when to issue a DT when getting the GETDELEGATIONTOKEN call. The DT
needs to be presented to the server in all subsequent usages.
Not all file systems issue delegation tokens, so it should not be a requirement
for WebHDFS-backed systems to either. Instead, OAuth2 credentials (generic
credentials per RFC spec section 4.3, explicit bearer/refresh tokens, or even
maybe plaintext password/usernames) should be able to be provided and passed
into whatever framework is actually handling the negotiation (ie, the filters).
bq. I don't think injecting any third-party payload (e.g., OAuth tokens) into
WebHdfsFileSystem make sense.
SPNEGO is already a third-party payload. This JIRA only adds OAuth as another
option.
> Support OAuth2 authentication in WebHDFS
> ----------------------------------------
>
> Key: HDFS-8155
> URL: https://issues.apache.org/jira/browse/HDFS-8155
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: webhdfs
> Reporter: Jakob Homan
> Assignee: Kai Zheng
>
> WebHDFS should be able to accept OAuth2 credentials.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
