The requirement is implemented as below:

1. Modify AuthenticationFilter so that it accepts multiple AuthenticationHandler via type as a comma separated list.
2. First AuthenticationHandler in the list is set as the default
3. To authenticate a user, AuthenticationFilter looks for authtype url parameter.
   If parameter is present, corresponding AuthenticationHandler is looked up by matching authtype with AuthenticationHandler's type value. Authentication is attempted using the matched AuthenticationHandler
   If the authtype parameter is not present, default Authentication is used.

I believe , the behavior is backward compatible.
Test AuthenticationFilter is modified to include unit tests for multiple mechanisms.
This is tested in our clusters.

This sounds similar to the AltKerberosAuthenticationHandler added in HADOOP-9054. The AltKerberosAuthenticationHandler uses Kerberos or some other AuthenticationHandler based on the user agent. For example, you can have all CLI access use Kerberos (by falling back to the KerberosAuthenticationHandler and all browsers use some custom authentication (by subclassing AltKerberosAuthenticationHandler to implement the custom authentication handler). You could have a chain of these authentication handlers to do more than two. Would this sufficient for your needs?

@rkanter, Using )AltKerberosAuthenticationHandler_ seems like a way to introduce multiple mechanisms as if its a single mechanism. This will result in one implementation which knows about all mechanisms. Not sure if that's the standard/right pattern to plugin multiple implementations of an interface to a framework.

The approach that we have used to specify the different AuthenticationHandler implementations directly in the configuration. The default implementation can be specified by keeping it at the beginning of the list.

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12625940/HADOOP-10307.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 1 new or modified test files.

+1 javac. The applied patch does not increase the total number of javac compiler warnings.

+1 javadoc. There were no new javadoc warning messages.

+1 eclipse:eclipse. The patch built with eclipse:eclipse.

+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of release audit warnings.

-1 core tests. The patch failed these unit tests in hadoop-common-project/hadoop-auth:

org.apache.hadoop.security.authentication.client.TestKerberosAuthenticator
org.apache.hadoop.security.authentication.client.TestPseudoAuthenticator

+1 contrib tests. The patch passed contrib unit tests.

Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/3560//testReport/
Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/3560//console

This message is automatically generated.

I think it might be more appropriate to put the authType into the HTTP header / cookie, since it can potentially conflicts with other web-based applications.

Benoy Antony, do you have any ideas how to apply the same approach on WebHDFS? There are similar requirements for WebHDFS since the new web UI now relies on WebHDFS to implement the file browser (HDFS-5891).

Sorry, I meant HDFS-5716 in the previous comment.

Haohui Mai I can take a stab applying the similar approach to webhdfs.

I think it might be more appropriate to put the authType into the HTTP header / cookie, since it can potentially conflicts with other web-based applications.

Could you please explain the conflict created by the new parameter - authtype ?
The parameter - authtype is used to the select authenticatonHandler. If authtype is not present, the default authenticationHandler is used. How will it help if this information is passed in a cookie ?

It will be nice if it allows to try auth filters in the chain one by one until one succeeds. The default one should be the first one. If the client specified one or more preferred methods, only those would be tried. I haven't looked at the code, but we may need a container auth filter to support trying multiple auth methods.

Isn't this already supported by HADOOP-9054?

Taking a different approach for this feature.

CompositeAuthenticationHandler is added.

• CompositeAuthenticationHandler accepts multiple AuthenticationHandler via configuration.
• When processing an authentication request, it picks up the AuthenticationHandler based on url parameter “authtype”.
• If “authtype” is not specified, it uses the default AuthenticationHandler(first one in the configured list of Authentication Handlers).
• For no-Browser access, there can be a separate AuthenticationHandler. This logic is borrowed from AltKerberosAuthenticationHandler.

Note 1: CompositeAuthenticationHandler offers the features of AltKerberosAuthenticationHandler. In addition, it allows configuring any number of AuthenticationHandlers. Based on the parameters and header values, it delegates control to the appropriate AuthenticationHandler.

Note 2: AnonymousAuthenticationHandler is added. With this handler, Anonymous access is achieved via a fixed account. Once can restrict the anonymous access privileges by restricting the permissions of the anonymous account.

+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12648661/HADOOP-10307.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 2 new or modified test files.

+1 javac. The applied patch does not increase the total number of javac compiler warnings.

+1 javadoc. There were no new javadoc warning messages.

+1 eclipse:eclipse. The patch built with eclipse:eclipse.

+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of release audit warnings.

+1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-auth.

+1 contrib tests. The patch passed contrib unit tests.

Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4017//testReport/
Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4017//console

This message is automatically generated.

Attaching the patch which sets the authentication type as "composite" in the tokens generated via CompositeAuthenticationHandler.

+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12650862/HADOOP-10307.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 2 new or modified test files.

+1 javac. The applied patch does not increase the total number of javac compiler warnings.

+1 javadoc. There were no new javadoc warning messages.

+1 eclipse:eclipse. The patch built with eclipse:eclipse.

+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

+1 release audit. The applied patch does not increase the total number of release audit warnings.

+1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-auth.

+1 contrib tests. The patch passed contrib unit tests.

Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/4088//testReport/
Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/4088//console

This message is automatically generated.

Haohui Mai, Kihwal Lee, do you have any comments on Benoy's latest patch?

i want to review this patch, i'll look at it monday morning.

Looking at the patch, it duplicates part of the logic done in HADOOP-9054 (using the user-agent), if we do that, then we should built on HADOOP-9054, not duplicating the code. Also, personally, I don't like the idea of query string param to indicate the auth scheme to use.

The other day, talking with Daryn Sharp, he suggested that to support multiple authentication schemes we could multiple WWW-Authenticate headers. I was not aware this was possible, I've checked around and it is possible. You can either have multiple schemes in the same WWW-Authenticate header (parsing that is a bit tricky and HttpClient does not support it yet (HTTPCLIENT-1489). Or you can have multiple WWW-Authenticate headers.

IMO, we should do as Daryn Sharp suggested me offline, add support for multiple authentication schemes. The AuthenticationFilter would have to support a list of AuthenticationHandlers, when a requests comes in and it is not authenticated (because of a cookie and because no handler found authentication info in it), then the response should include the challenges of all AuthenticationHandlers. Then the client should choose the strongest one it supports.

Thanks for the comments, Alejandro Abdelnur. I like the idea of using headers. I'll explore that and update the patch.

HI Benoy Antony - I am curious where this patch stands. I am investigating the ability to add multiple authentication mechanisms at the moment and don't want to duplicate efforts here.

+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12650862/HADOOP-10307.patch
against trunk revision 825923f.

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 2 new or modified test files.

+1 javac. The applied patch does not increase the total number of javac compiler warnings.

+1 javadoc. There were no new javadoc warning messages.

+1 eclipse:eclipse. The patch built with eclipse:eclipse.

+1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings.

+1 release audit. The applied patch does not increase the total number of release audit warnings.

+1 core tests. The patch passed unit tests in hadoop-common-project/hadoop-auth.

Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/5458//testReport/
Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/5458//console

This message is automatically generated.

Larry McCay, Thanks for asking. I didn't do much on this Jira.
We have been successfully using patch and CompositeAuthenticationHandler in our production clusters and found to suit our needs.

Benoy Antony This probably a duplicate of HADOOP-12082 ?

-1 overall

This message was automatically generated.