Zhijie Shen commented on YARN-2247:

bq. The current implementation uses the standard http authentication for 
hadoop. Users can set it to simple if they choose.

I was trying to make the point that when kerberos authentication is not used, 
simple authentication is not implicitly set, isn't it? In this case, without 
the authentication filter, we cannot identify the user via HTTP interface, such 
that we cannot behave correctly for those operations that require the knowledge 
of user information, such as submit/kill an application.

One step back, and let's look at the analog RPC interfaces. By default, the 
authentication is SIMPLE, and at the server side, we can still identify who the 
user is, such that the feature such as ACLs are is still working in the SIMPLE 

bq. For now I'd like to use the same configs as the standard hadoop http auth. 
I'm open to changing them if we feel strongly about it in the future.

It's okay to keep the configuration same. Just think it out loudly. If so, you 
may not want to add RM_WEBAPP_USE_YARN_AUTH_FILTER at all, and not load 
YarnAuthenticationFilterInitializer programatically. The rationales behind them 
are similar. Previously, I tried to add TimelineAuthenticationFilterInitializer 
programmatically because I find the same http auth config applies to different 
daemons, and I think it's annoying that at a single node cluster, I want to 
config something only for timeline server, it will affect others. Afterwards, I 
tried to make timeline server to use a set of configs with timeline-service 
prefix. This is what we did for the RPC interface configurations.

bq. I didn't understand - can you explain further?

Let's take RMWebServices#getApp as an example. Previously we don't have (at 
least don't know) the auth filter, such that we cannot detect the user. 
Therefore, we don't check the ACLs, and simply get the application from 
RMContext and return the user. Now, we have the auth filter, and we can 
identify the user. Hence, it's possible for use to fix this API to only return 
the application information to the user that has the access. This is also 
another reason why I suggest to always have authentication filter on, whether 
it is simple or kerberos.

bq. Am I looking at the wrong file?

This is the right file, but I'm afraid it is not the correct logic. 
AuthenticationFilter accept null secret file. However, if we use 
AuthenticationFilterInitializer to construct AuthenticationFilter, the null 
case is denied. I previously open a ticket for this issue (HADOOP-10600).

> Allow RM web services users to authenticate using delegation tokens
> -------------------------------------------------------------------
>                 Key: YARN-2247
>                 URL: https://issues.apache.org/jira/browse/YARN-2247
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Varun Vasudev
>            Assignee: Varun Vasudev
>            Priority: Blocker
>         Attachments: apache-yarn-2247.0.patch, apache-yarn-2247.1.patch, 
> apache-yarn-2247.2.patch
> The RM webapp should allow users to authenticate using delegation tokens to 
> maintain parity with RPC.

This message was sent by Atlassian JIRA

Reply via email to