[
https://issues.apache.org/jira/browse/HDFS-5796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345676#comment-14345676
]
Arun Suresh commented on HDFS-5796:
-----------------------------------
[~aw], thanks for the comments, I think we are talking about similar things,
but :
bq. This is exactly the purpose of the AltKerberos filter and the one we're
using...
please correct me if Im wrong, but looking a the code in hadoop trunk, I don't
think AltKerberos is currently used.
The patches I have posted are an attempt at introducing the AltKerberos auth
handler for Browser access.
So that we are on the same page, we agree using AltKerberos Handler is the
right approach.. but I think we should agree on what exactly should be the
alternate mechanism...
I vote, the default case should be to bring back the old "dr.who" user
(unfortunately, I feel this is closer to the glass house situation you
mentioned), or a scheme like what I proposed in my patches, where the proxy
user has to have a proper kerberos principal and keytab. And allow the specific
alternate mechanism to be configured.
Thoughts ?
> The file system browser in the namenode UI requires SPNEGO.
> -----------------------------------------------------------
>
> Key: HDFS-5796
> URL: https://issues.apache.org/jira/browse/HDFS-5796
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.5.0
> Reporter: Kihwal Lee
> Assignee: Arun Suresh
> Priority: Blocker
> Attachments: HDFS-5796.1.patch, HDFS-5796.1.patch, HDFS-5796.2.patch,
> HDFS-5796.3.patch, HDFS-5796.3.patch
>
>
> After HDFS-5382, the browser makes webhdfs REST calls directly, requiring
> SPNEGO to work between user's browser and namenode. This won't work if the
> cluster's security infrastructure is isolated from the regular network.
> Moreover, SPNEGO is not supposed to be required for user-facing web pages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
