You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Benoy Antony (JIRA)" <ji...@apache.org> on 2015/04/10 10:09:13 UTC

[jira] [Comment Edited] (HADOOP-10709) Reuse Filters across web apps

    [ https://issues.apache.org/jira/browse/HADOOP-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14489139#comment-14489139 ] 

Benoy Antony edited comment on HADOOP-10709 at 4/10/15 8:08 AM:
----------------------------------------------------------------

h3. Two Drawbacks for org.apache.hadoop.hdfs.web.AuthFilter

1. org.apache.hadoop.hdfs.web.AuthFilter requires specifying the full set of parameters for webhdfs authentication. This jira aims to avoid that additional specification by reusing the Filter instance used for General HTTP Authentication. 

2. org.apache.hadoop.hdfs.web.AuthFilter currently allows only Spnego/Pseudo Authentication Handlers.
The jira allows custom Authentication Handler by reusing the Filter instance used for General HTTP Authentication. 


This jira basically adds two abilities.

1. Allows dfs.web.authentication.filter to accept multiple values
2. Allows the values of dfs.web.authentication.filter to be a class name or the name of another Filter instance. The 

h3. config with  org.apache.hadoop.hdfs.web.AuthFilter

{code}
<property>
  <name>dfs.web.authentication.filter</name>
  <value>org.apache.hadoop.hdfs.web.AuthFilter</value>
</property>
{code}


h3. config with org.apache.hadoop.hdfs.web.TokenAuthFilter 
{code}
<property>
  <name>dfs.web.authentication.filter</name>
  <value>org.apache.hadoop.hdfs.web.TokenAuthFilter,authentication</value>
</property>
{code}

org.apache.hadoop.hdfs.web.AuthFilter and org.apache.hadoop.hdfs.web.TokenAuthFilter are similar in that both skips Authentication if DelegationToken is present. 

If DelegationToken is NOT present, both of them triggers primary Authentication. The difference is in the way primary authentication is carried out. 
org.apache.hadoop.hdfs.web.AuthFilter extends from AuthenticationFilter and initializes itself with config properties prefixed with “dfs.web.authentication.”
org.apache.hadoop.hdfs.web.AuthFilter will invoke its parent’s (AuthenticationFilter) logic.

org.apache.hadoop.hdfs.web.TokenAuthFilter invokes the next Filter in chain. Based on the above configuration, it will invoke the filter instance named “authentication”. This is the filter instance initialized with with config properties prefixed with hadoop.http.authentication.

As a side note, org.apache.hadoop.hdfs.web.TokenAuthFilter is optional as a user can plug it in via configuration. 

I hope this clarification is helpful. 


was (Author: benoyantony):
h3. Two Drawbacks for org.apache.hadoop.hdfs.web.AuthFilter

1. org.apache.hadoop.hdfs.web.AuthFilter requires specifying the full set of parameters for webhdfs authentication. This jira aims to avoid that additional specification by reusing the Filter instance used for General HTTP Authentication. 

2. org.apache.hadoop.hdfs.web.AuthFilter currently allows only Spnego/Pseudo Authentication Handlers.
The jira allows custom Authentication Handler by reusing the Filter instance used for General HTTP Authentication. 


This jira basically adds two abilities.

1. Allows dfs.web.authentication.filter to accept multiple values
2. Allows the values of dfs.web.authentication.filter to be a class name or the name of another Filter instance. The 

h3. config with  org.apache.hadoop.hdfs.web.AuthFilter

{code}
<property>
  <name>dfs.web.authentication.filter</name>
  <value>org.apache.hadoop.hdfs.web.AuthFilter</value>
</property>
{code}


h3. config with org.apache.hadoop.hdfs.web.TokenAuthFilter 
{code}
<property>
  <name>dfs.web.authentication.filter</name>
  <value>org.apache.hadoop.hdfs.web.TokenAuthFilter,authentication</value>
</property>
{code}

org.apache.hadoop.hdfs.web.AuthFilter and org.apache.hadoop.hdfs.web.TokenAuthFilter are similar in that both skips Authentication if DelegationToken is present. 

If DelegationToken is NOT present, both of them triggers primary Authentication. The difference is in the way primary authentication is carried out. 
org.apache.hadoop.hdfs.web.AuthFilter extends from AuthenticationFilter and initializes itself with config properties prefixed with “dfs.web.authentication.”
org.apache.hadoop.hdfs.web.AuthFilter it will invoke its parent’s (AuthenticationFilter) logic.

org.apache.hadoop.hdfs.web.TokenAuthFilter invokes the next Filter in chain. Based on the above configuration, it will invoke the filter instance named “authentication”. This is the filter instance initialized with with config properties prefixed with hadoop.http.authentication.

As a side note, org.apache.hadoop.hdfs.web.TokenAuthFilter is optional as a user can plug it in via configuration. 

I hope this clarification is helpful. 

> Reuse Filters across web apps
> -----------------------------
>
>                 Key: HADOOP-10709
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10709
>             Project: Hadoop Common
>          Issue Type: Improvement
>          Components: security
>            Reporter: Benoy Antony
>            Assignee: Benoy Antony
>         Attachments: HADOOP-10709-002.patch, HADOOP-10709.patch, configForFilterReuse.xml
>
>
> Currently, we need to define separate authentication filters for webhdfs and general webui. This also involves defining parameters for those filters.
> It will be better if one could reuse filters for web apps if desired. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)