[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16128142#comment-16128142 ] Allen Wittenauer commented on HADOOP-12082: --- Is this going to get documented? > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Fix For: 2.8.0, 3.0.0-alpha2 > > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2-003.patch, > HADOOP-12082-branch-2.8-001.patch, HADOOP-12082-branch-2.8-002.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail:
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15605624#comment-15605624 ] Benoy Antony commented on HADOOP-12082: --- [~hgadre], Could you please open a related jira to update the documentation so that users learn how to make use of the new AuthenticationHandlers ? It will be very useful. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Fix For: 2.8.0, 3.0.0-alpha2 > > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2-003.patch, > HADOOP-12082-branch-2.8-001.patch, HADOOP-12082-branch-2.8-002.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604343#comment-15604343
]
Hadoop QA commented on HADOOP-12082:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
1s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
54s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
28s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
32s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
30s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
26s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
32s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
42s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
9s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
13s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
27s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
32s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
35s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
32s{color} | {color:green} root: The patch generated 0 new + 151 unchanged - 6
fixed = 151 total (was 157) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
23s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
38s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
16s{color} | {color:green} hadoop-project in the patch passed with JDK
v1.7.0_111. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
29s{color} | {color:green} hadoop-auth in the patch passed with JDK v1.7.0_111.
{color} |
| {color:green}+1{color} | {color:green} unit {color} |
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604152#comment-15604152 ] Benoy Antony commented on HADOOP-12082: --- I agree @Hgarde. I started a ReBuild just to be on the safe side. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2-003.patch, > HADOOP-12082-branch-2.8-001.patch, HADOOP-12082-branch-2.8-002.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail:
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15598534#comment-15598534 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~benoyantony] The unit test failure and whitespace related error are unrelated to my patch. Please let me know if anything required from my end. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2-003.patch, > HADOOP-12082-branch-2.8-001.patch, HADOOP-12082-branch-2.8-002.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail:
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15598506#comment-15598506
]
Hadoop QA commented on HADOOP-12082:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
58s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
34s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
37s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
31s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
27s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
32s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
11s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
14s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
26s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
29s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
34s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
29s{color} | {color:green} root: The patch generated 0 new + 151 unchanged - 6
fixed = 151 total (was 157) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 47 line(s) that end in whitespace. Use
git apply --whitespace=fix <>. Refer
https://git-scm.com/docs/git-apply {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
23s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
38s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
15s{color} | {color:green} hadoop-project in the patch passed with JDK
v1.7.0_111. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
24s{color} | {color:green} hadoop-auth in the patch passed with
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15597193#comment-15597193 ] Benoy Antony commented on HADOOP-12082: --- Yes, _multi-scheme_ and +ldp_ can be plugged in like any other AuthenticationHandler. It will be good idea to update the relevant documentation with this. But let us do it in a different jira. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8-002.patch, HADOOP-12082-branch-2.8.patch, > HADOOP-12082-branch-2.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail:
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15597187#comment-15597187 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~yuanbo] bq. I guess it's hard for NameNode or ResourceManager's http server to take advantage of your work, since http server is a thread in NameNode or ResourceManager and the webapp is packaged into jar. It's not able to change web.xml unless the jar is replaced. I don't think so. The httpfs-site.xml file contains the configuration options for the authentication filter. Please refer to following links https://hadoop.apache.org/docs/r2.6.4/hadoop-hdfs-httpfs/ServerSetup.html https://hadoop.apache.org/docs/r2.6.4/hadoop-hdfs-httpfs/httpfs-default.html Specifically refer to following params for kerberos authentication, httpfs.authentication.type httpfs.authentication.kerberos.principal httpfs.authentication.kerberos.keytab As per this doc, the valid values for "httpfs.authentication.type" are *simple* OR *kerberos*. May be we need update the code to consider "ldap" and "multi-scheme" as valid values as well. The similar changes would probably work for ResourceManager's HTTP server. [~benoyantony] what do you think? > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8-002.patch, HADOOP-12082-branch-2.8.patch, > HADOOP-12082-branch-2.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15597000#comment-15597000
]
Yuanbo Liu commented on HADOOP-12082:
-
[~hgadre] Thanks for your response.
{quote}
The jira addresses the requirement where more tha
{quote}
Now I understand what issue this JIRA address. The delegation filter which I'm
looking for is similar with your idea, the first auth is SPENGO auth, and the
second is proxy auth.
{quote}
The authentication handler is configured as part of configuring Hadoop
AuthenticationFilter. This is typically done via web.xml
{quote}
I have went though Oozie configuration, also Configuration.md again. I guess
it's hard for NameNode or ResourceManager's http server to take advantage of
your work, since http server is a thread in NameNode or ResourceManager and the
webapp is packaged into jar. It's not able to change web.xml unless the jar is
replaced.
So I think it's designed for third-party projects which depend on Hadoop-Auth,
right?
> Support multiple authentication schemes via AuthenticationFilter
>
>
> Key: HADOOP-12082
> URL: https://issues.apache.org/jira/browse/HADOOP-12082
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.6.0
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
> Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch,
> HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch,
> HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch,
> HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch,
> HADOOP-12082-branch-2.8-002.patch, HADOOP-12082-branch-2.8.patch,
> HADOOP-12082-branch-2.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch,
> hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch,
> hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch,
> multi-scheme-auth-support-poc.patch
>
>
> The requirement is to support LDAP based authentication scheme via Hadoop
> AuthenticationFilter. HADOOP-9054 added a support to plug-in custom
> authentication scheme (in addition to Kerberos) via
> AltKerberosAuthenticationHandler class. But it is based on selecting the
> authentication mechanism based on User-Agent HTTP header which does not
> conform to HTTP protocol semantics.
> As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html]
> - HTTP protocol provides a simple challenge-response authentication mechanism
> that can be used by a server to challenge a client request and by a client to
> provide the necessary authentication information.
> - This mechanism is initiated by server sending the 401 (Authenticate)
> response with ‘WWW-Authenticate’ header which includes at least one challenge
> that indicates the authentication scheme(s) and parameters applicable to the
> Request-URI.
> - In case server supports multiple authentication schemes, it may return
> multiple challenges with a 401 (Authenticate) response, and each challenge
> may use a different auth-scheme.
> - A user agent MUST choose to use the strongest auth-scheme it understands
> and request credentials from the user based upon that challenge.
> The existing Hadoop authentication filter implementation supports Kerberos
> authentication scheme and uses ‘Negotiate’ as the challenge as part of
> ‘WWW-Authenticate’ response header. As per the following documentation,
> ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows
> NTLM) authentication schemes.
> [SPNEGO-based Kerberos and NTLM HTTP
> Authentication|http://tools.ietf.org/html/rfc4559]
> [Understanding HTTP
> Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx]
> On the other hand for LDAP authentication, typically ‘Basic’ authentication
> scheme is used (Note TLS is mandatory with Basic authentication scheme).
> http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html
> Hence for this feature, the idea would be to provide a custom implementation
> of Hadoop AuthenticationHandler and Authenticator interfaces which would
> support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via
> Basic auth challenge). During the authentication phase, it would send both
> the challenges and let client pick the appropriate one. If client responds
> with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos
> authentication. If client responds with an ‘Authorization’ header tagged with
> ‘Basic’ - it will use LDAP authentication.
> Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be
> configured to use one scheme over the other e.g.
> - curl tool supports option to use either Kerberos (via --negotiate flag) or
> username/password based
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15596997#comment-15596997 ] Benoy Antony commented on HADOOP-12082: --- committed to branch-2.8. Thanks for the effort and contribution [~hgadre] . Could you please provide a patch for the branch-2 as well ? I cannot cherry-pick from branch-2.8 to branch-2 . > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8-002.patch, HADOOP-12082-branch-2.8.patch, > HADOOP-12082-branch-2.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail:
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15596871#comment-15596871 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~benoyantony] What would recommend regarding the error related to whitespaces? This file is not part of my patch... > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8-002.patch, HADOOP-12082-branch-2.8.patch, > HADOOP-12082-branch-2.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail:
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15596802#comment-15596802
]
Hadoop QA commented on HADOOP-12082:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 3m
8s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
7s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
42s{color} | {color:green} branch-2.8 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
11s{color} | {color:green} branch-2.8 passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
37s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
42s{color} | {color:green} branch-2.8 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
18s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
25s{color} | {color:green} branch-2.8 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
33s{color} | {color:green} branch-2.8 passed with JDK v1.7.0_111 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
27s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
3s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
45s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} root: The patch generated 0 new + 138 unchanged - 6
fixed = 138 total (was 144) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 47 line(s) that end in whitespace. Use
git apply --whitespace=fix <>. Refer
https://git-scm.com/docs/git-apply {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
32s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
41s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
15s{color} | {color:green} hadoop-project in the patch passed with JDK
v1.7.0_111. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
27s{color} | {color:green} hadoop-auth in the
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15596581#comment-15596581 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~yuanbo] bq. When you said LDAP based authentication, did you mean authentication filter which supports delegation? The jira addresses the requirement where more than one authentication mode need to be configured e.g. consider a case where some of the users can not be authenticated using kerberos since they reside outside the kerberos domain. So with this mechanism, you can configure two authentication schemes (a) SPNEGO scheme using kerberos auth and (b) BASIC scheme using LDAP auth. Hence the users which are outside kerberos domain can provide username/password to authenticate against LDAP (or Active Directory) server. Also the underlying framework is extensible so you can implement different mechanisms as well e.g. instead of LDAP auth - you can use a database backend for storing the credentials. For this - you will need to provide a different authentication handler implementation using LdapAuthenticationHandler.java as a reference. BTW HADOOP-9054 also targeted the same use-case, although that implementation was not confirming the HTTP protocol semantics. More explanation is available in the jira description. bq. I was anticipating there were some descriptions about configuration work of core-site/hdfs-site, but there weren't. The authentication handler is configured as part of configuring Hadoop AuthenticationFilter. This is typically done via web.xml (or other web container/application specific means). e.g. following link provide steps to configure authentication handler for Oozie https://oozie.apache.org/docs/4.2.0/ENG_Custom_Authentication.html#Provide_Custom_Authentication_to_Oozie_Server > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593683#comment-15593683 ] Yuanbo Liu commented on HADOOP-12082: - [~hgadre] Thanks for your work. It seems a long time JIRA, and I doesn't catch up much context of this issue. When you said LDAP based LDAP based authentication, did you mean authentication filter which supports delegation? If so, I'm looking forwards to your work, because it would help some proxy servers such as Knox to deal with more http requests which require proxy user. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593554#comment-15593554 ] Andrew Wang commented on HADOOP-12082: -- No real reason, I just backported it for you. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593537#comment-15593537 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~andrew.wang] Is there a reason why we have not backported HADOOP-12859 to branch-2.8 ? This is causing problems in backporting this patch to branch-2.8 > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands,
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593334#comment-15593334 ] Hrishikesh Gadre commented on HADOOP-12082: --- Yes I just changed the method param name. The method name is still same. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593322#comment-15593322 ] Benoy Antony commented on HADOOP-12082: --- Let's keep the same method names in all branches. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15593181#comment-15593181 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~benoyantony] bq. Any reason to not use primitive for enableStartTls and disableHostNameVerification ? I think , that will fix the checkstyle errors. No specific reason. BTW jenkins didn't report any checkstyle warnings for the patch against trunk (which had the identical code). I have resubmitted the patch by renaming the method parameter. Let's see if it fixes the issue. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2-002.patch, HADOOP-12082-branch-2.8-001.patch, > HADOOP-12082-branch-2.8.patch, HADOOP-12082-branch-2.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication]
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15592268#comment-15592268 ] Benoy Antony commented on HADOOP-12082: --- [~hgadre], Any reason to not use primitive for _enableStartTls_ and _disableHostNameVerification_ ? I think , that will fix the checkstyle errors. The whitespace issues seem to occur on file that's not modified by your patch ? > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082-branch-2-001.patch, > HADOOP-12082-branch-2.8-001.patch, HADOOP-12082-branch-2.8.patch, > HADOOP-12082-branch-2.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail:
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590673#comment-15590673
]
Hadoop QA commented on HADOOP-12082:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
2s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
9s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
38s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
32s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
34s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
13s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
19s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
27s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
26s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
8s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
43s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
30s{color} | {color:green} root: The patch generated 0 new + 151 unchanged - 6
fixed = 151 total (was 157) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 47 line(s) that end in whitespace. Use
git apply --whitespace=fix <>. Refer
https://git-scm.com/docs/git-apply {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
28s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
37s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
15s{color} | {color:green} hadoop-project in the patch passed with JDK
v1.7.0_111. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
23s{color} | {color:green} hadoop-auth in the patch passed with
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590666#comment-15590666
]
Hadoop QA commented on HADOOP-12082:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
43s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
30s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
13s{color} | {color:green} branch-2.8 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
17s{color} | {color:green} branch-2.8 passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
39s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s{color} | {color:green} branch-2.8 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
10s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
15s{color} | {color:green} branch-2.8 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
28s{color} | {color:green} branch-2.8 passed with JDK v1.7.0_111 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
21s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
28s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
28s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
1m 11s{color} | {color:orange} root: The patch generated 2 new + 138 unchanged
- 5 fixed = 140 total (was 143) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 47 line(s) that end in whitespace. Use
git apply --whitespace=fix <>. Refer
https://git-scm.com/docs/git-apply {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
24s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
40s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
12s{color} | {color:green} hadoop-project in the patch passed with JDK
v1.7.0_111. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
16s{color} | {color:green} hadoop-auth in
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590460#comment-15590460
]
Hrishikesh Gadre commented on HADOOP-12082:
---
[~benoyantony] Regarding patch for branch-2.8,
Following checkstyle errors seem bogus to me. Also these were not reported for
the patch I submitted against trunk.
./hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/LdapAuthenticationHandler.java:118:
public void setEnableStartTls(Boolean enableStartTls) {:41: 'enableStartTls'
hides a field.
./hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/LdapAuthenticationHandler.java:131:
Boolean disableHostNameVerification) {:15: 'disableHostNameVerification'
hides a field.
Also the following whitespace errors reported are for a file which I can't find
in branch-2.8
https://builds.apache.org/job/PreCommit-HADOOP-Build/10830/artifact/patchprocess/whitespace-eol.txt
> Support multiple authentication schemes via AuthenticationFilter
>
>
> Key: HADOOP-12082
> URL: https://issues.apache.org/jira/browse/HADOOP-12082
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.6.0
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
> Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch,
> HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch,
> HADOOP-12082-006.patch, HADOOP-12082-branch-2.8.patch,
> HADOOP-12082-branch-2.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch,
> hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch,
> hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch,
> multi-scheme-auth-support-poc.patch
>
>
> The requirement is to support LDAP based authentication scheme via Hadoop
> AuthenticationFilter. HADOOP-9054 added a support to plug-in custom
> authentication scheme (in addition to Kerberos) via
> AltKerberosAuthenticationHandler class. But it is based on selecting the
> authentication mechanism based on User-Agent HTTP header which does not
> conform to HTTP protocol semantics.
> As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html]
> - HTTP protocol provides a simple challenge-response authentication mechanism
> that can be used by a server to challenge a client request and by a client to
> provide the necessary authentication information.
> - This mechanism is initiated by server sending the 401 (Authenticate)
> response with ‘WWW-Authenticate’ header which includes at least one challenge
> that indicates the authentication scheme(s) and parameters applicable to the
> Request-URI.
> - In case server supports multiple authentication schemes, it may return
> multiple challenges with a 401 (Authenticate) response, and each challenge
> may use a different auth-scheme.
> - A user agent MUST choose to use the strongest auth-scheme it understands
> and request credentials from the user based upon that challenge.
> The existing Hadoop authentication filter implementation supports Kerberos
> authentication scheme and uses ‘Negotiate’ as the challenge as part of
> ‘WWW-Authenticate’ response header. As per the following documentation,
> ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows
> NTLM) authentication schemes.
> [SPNEGO-based Kerberos and NTLM HTTP
> Authentication|http://tools.ietf.org/html/rfc4559]
> [Understanding HTTP
> Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx]
> On the other hand for LDAP authentication, typically ‘Basic’ authentication
> scheme is used (Note TLS is mandatory with Basic authentication scheme).
> http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html
> Hence for this feature, the idea would be to provide a custom implementation
> of Hadoop AuthenticationHandler and Authenticator interfaces which would
> support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via
> Basic auth challenge). During the authentication phase, it would send both
> the challenges and let client pick the appropriate one. If client responds
> with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos
> authentication. If client responds with an ‘Authorization’ header tagged with
> ‘Basic’ - it will use LDAP authentication.
> Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be
> configured to use one scheme over the other e.g.
> - curl tool supports option to use either Kerberos (via --negotiate flag) or
> username/password based authentication (via --basic and -u flags).
> - Apache HttpClient library can be configured to use specific authentication
> scheme.
>
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590298#comment-15590298
]
Hadoop QA commented on HADOOP-12082:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
24s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
47s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
55s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
41s{color} | {color:green} branch-2.8 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
17s{color} | {color:green} branch-2.8 passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
14s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
39s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
48s{color} | {color:green} branch-2.8 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
39s{color} | {color:green} branch-2.8 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
31s{color} | {color:green} branch-2.8 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
35s{color} | {color:green} branch-2.8 passed with JDK v1.7.0_111 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
30s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
29s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
14s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
14s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
1m 20s{color} | {color:orange} root: The patch generated 4 new + 138 unchanged
- 5 fixed = 142 total (was 143) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 47 line(s) that end in whitespace. Use
git apply --whitespace=fix <>. Refer
https://git-scm.com/docs/git-apply {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
23s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
38s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
16s{color} | {color:green} hadoop-project in the patch passed with JDK
v1.7.0_111. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
29s{color} | {color:green} hadoop-auth in
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15590201#comment-15590201
]
Hadoop QA commented on HADOOP-12082:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m
54s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
57s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
41s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
41s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
27s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
27s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
31s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
43s{color} | {color:green} branch-2 passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
7s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
11s{color} | {color:green} branch-2 passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
25s{color} | {color:green} branch-2 passed with JDK v1.7.0_111 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
26s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
33s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
31s{color} | {color:green} root: The patch generated 0 new + 151 unchanged - 6
fixed = 151 total (was 157) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 48 line(s) that end in whitespace. Use
git apply --whitespace=fix <>. Refer
https://git-scm.com/docs/git-apply {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
24s{color} | {color:green} the patch passed with JDK v1.8.0_101 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
37s{color} | {color:green} the patch passed with JDK v1.7.0_111 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
14s{color} | {color:green} hadoop-project in the patch passed with JDK
v1.7.0_111. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m
23s{color} | {color:green} hadoop-auth in the patch passed with
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15587473#comment-15587473 ] Benoy Antony commented on HADOOP-12082: --- Committed to trunk. Thanks for the contribution [~hgadre]. Could you please upload the patches for branch-2 and branch-2.8 ? I will commit them also. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15587383#comment-15587383 ] Hudson commented on HADOOP-12082: - SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #10636 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/10636/]) HADOOP-12082 Support multiple authentication schemes via (benoy: rev 4bca385241c0fc8ff168c7b0f2984a7aed2c7492) * (edit) hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/token/delegation/web/DelegationTokenAuthenticationHandler.java * (add) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/package-info.java * (add) hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestLdapAuthenticationHandler.java * (add) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationHandlerUtil.java * (edit) hadoop-project/pom.xml * (edit) hadoop-common-project/hadoop-auth/pom.xml * (add) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/MultiSchemeAuthenticationHandler.java * (add) hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/TestMultiSchemeAuthenticationHandler.java * (edit) hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/token/delegation/web/DelegationTokenAuthenticationFilter.java * (add) hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/token/delegation/web/MultiSchemeDelegationTokenAuthenticationHandler.java * (edit) hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/client/TestKerberosAuthenticator.java * (edit) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/client/KerberosAuthenticator.java * (edit) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationHandler.java * (add) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/HttpConstants.java * (add) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/LdapAuthenticationHandler.java * (add) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/CompositeAuthenticationHandler.java * (edit) hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationFilter.java * (edit) hadoop-common-project/hadoop-auth/src/site/markdown/Configuration.md * (add) hadoop-common-project/hadoop-auth/src/test/java/org/apache/hadoop/security/authentication/server/LdapConstants.java > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15584478#comment-15584478 ] Benoy Antony commented on HADOOP-12082: --- +1 Will commit tomorrow if there are no other comments. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583722#comment-15583722 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~benoyantony] The patch is looking good now. Can you please take a look? > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082-005.patch, > HADOOP-12082-006.patch, HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583716#comment-15583716
]
Hadoop QA commented on HADOOP-12082:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
19s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m
30s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
10s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
24s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
36s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
41s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
9s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
36s{color} | {color:green} root: The patch generated 0 new + 151 unchanged - 6
fixed = 151 total (was 157) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
13s{color} | {color:green} hadoop-project in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
40s{color} | {color:green} hadoop-auth in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m
3s{color} | {color:green} hadoop-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
26s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 77m 7s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:9560f25 |
| JIRA Issue | HADOOP-12082 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12833808/HADOOP-12082-006.patch
|
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit xml findbugs checkstyle |
| uname | Linux 1c435914cc4f 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15583258#comment-15583258
]
Hadoop QA commented on HADOOP-12082:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
40s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
48s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
24s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
35s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
41s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
9s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
58s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
1m 38s{color} | {color:orange} root: The patch generated 1 new + 151 unchanged
- 6 fixed = 152 total (was 157) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
13s{color} | {color:green} hadoop-project in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
37s{color} | {color:green} hadoop-auth in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m
51s{color} | {color:green} hadoop-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 75m 3s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:9560f25 |
| JIRA Issue | HADOOP-12082 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12833778/HADOOP-12082-005.patch
|
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit xml findbugs checkstyle |
| uname | Linux 0d280a4e8249 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15581379#comment-15581379 ] Benoy Antony commented on HADOOP-12082: --- Could you please fix the checkstyle warnings also ? > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082-003.patch, HADOOP-12082-004.patch, HADOOP-12082.patch, > hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15581117#comment-15581117
]
Hadoop QA commented on HADOOP-12082:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
41s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
46s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
27s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
25s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
35s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
42s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
10s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
54s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
1m 32s{color} | {color:orange} root: The patch generated 27 new + 151 unchanged
- 6 fixed = 178 total (was 157) {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
3s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
15s{color} | {color:green} hadoop-project in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
35s{color} | {color:green} hadoop-auth in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m
11s{color} | {color:green} hadoop-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 71m 54s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:9560f25 |
| JIRA Issue | HADOOP-12082 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12833669/HADOOP-12082-004.patch
|
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit xml findbugs checkstyle |
| uname | Linux 42961314b2db 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15580890#comment-15580890
]
Hadoop QA commented on HADOOP-12082:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
35s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
44s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
48s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
26s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
35s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
47s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
10s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
48s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
1m 33s{color} | {color:orange} root: The patch generated 27 new + 151 unchanged
- 6 fixed = 178 total (was 157) {color} |
| {color:red}-1{color} | {color:red} mvnsite {color} | {color:red} 0m
21s{color} | {color:red} hadoop-auth in the patch failed. {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
15s{color} | {color:green} hadoop-project in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
35s{color} | {color:green} hadoop-auth in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m
13s{color} | {color:green} hadoop-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 73m 30s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:9560f25 |
| JIRA Issue | HADOOP-12082 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12833662/HADOOP-12082-003.patch
|
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit xml findbugs checkstyle |
| uname | Linux da202271165f 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15573184#comment-15573184
]
Hadoop QA commented on HADOOP-12082:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
48s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
25s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
41s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 1m
33s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
35s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
56s{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
16s{color} | {color:green} trunk passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
4s{color} | {color:green} the patch passed {color} |
| {color:orange}-0{color} | {color:orange} checkstyle {color} | {color:orange}
1m 42s{color} | {color:orange} root: The patch generated 124 new + 155
unchanged - 2 fixed = 279 total (was 157) {color} |
| {color:red}-1{color} | {color:red} mvnsite {color} | {color:red} 0m
22s{color} | {color:red} hadoop-auth in the patch failed. {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
3s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hadoop-project {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
43s{color} | {color:red} hadoop-common-project/hadoop-auth generated 3 new + 0
unchanged - 0 fixed = 3 total (was 0) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
19s{color} | {color:red} hadoop-auth in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
14s{color} | {color:green} hadoop-project in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
38s{color} | {color:green} hadoop-auth in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m
40s{color} | {color:green} hadoop-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 79m 3s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hadoop-common-project/hadoop-auth |
| | Found reliance on default encoding in
org.apache.hadoop.security.authentication.server.LdapAuthenticationHandler.authenticate(HttpServletRequest,
HttpServletResponse):in
org.apache.hadoop.security.authentication.server.LdapAuthenticationHandler.authenticate(HttpServletRequest,
HttpServletResponse): new String(byte[]) At
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15573112#comment-15573112 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~benoyantony] Done ! > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572920#comment-15572920 ] Benoy Antony commented on HADOOP-12082: --- Looks good. Could you please "submit patch" ? > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082-002.patch, > HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15570578#comment-15570578 ] Benoy Antony commented on HADOOP-12082: --- Looks good. Just a suggestion for documentation. I think , its more appropriate to change the filter-name in the example to "authFilter" instead "kerberosFilter" . > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082-001.patch, HADOOP-12082.patch, > hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15556887#comment-15556887 ] Kai Zheng commented on HADOOP-12082: Hi [~hgadre], Sorry for the inconvenience and the late reply (in PRC holiday). bq. Specifically I need to add unit tests to verify the LDAP authentication functionality. Do these tests relate to Kerberos or not? Or basically they need an LDAP backend, instead of a KDC, right? bq. Can we use the LdapBackend provided by Apache Kerby for this usecase? Or should I initialize the DirectoryService API for my unit tests? It depends on what these tests actually need. If they just use an LDAP server, I thought you could have some options, like the DirectoryService API. The Kerby LdapBackend is only for the Kerby KDC situation so if you don't need a KDC, then it's not good for it. > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15550102#comment-15550102 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~kai.zhang] [~jiajia] I need your help to get this patch working against the trunk. Specifically I need to add unit tests to verify the LDAP authentication functionality. Earlier I was using the reference of DirectoryService available in the MiniKdc to bootstrap the LDAP server. It looks like as part of HADOOP-12911, the MiniKdc was refactored to remove this reference. I am wondering what is the best way going forward for adding these tests. Can we use the LdapBackend provided by Apache Kerby for this usecase? Or should I initialize the DirectoryService API for my unit tests? > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214811#comment-15214811 ] Benoy Antony commented on HADOOP-12082: --- Thanks [~hgadre], The patch filename convention is is like this : HADOOP-12082-001.patch Could you please add the documentation regarding this feature ? You can start with hadoop-common-project/hadoop-auth/src/site/markdown/index.md > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: HADOOP-12082.patch, hadoop-ldap-auth-v2.patch, > hadoop-ldap-auth-v3.patch, hadoop-ldap-auth-v4.patch, > hadoop-ldap-auth-v5.patch, hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15209437#comment-15209437 ] Benoy Antony commented on HADOOP-12082: --- Thanks for [~hgadre] for taking care of the comments. Here are the comments on the new patch. _nits_ # unnecessary change in hadoop-common-project/hadoop-minikdc/src/main/resources/minikdc.ldiff # Reference to Minikdc in MiniLdap#48 # Does it make sense to move move the ldap related test classes under a new package , say minildap ? # It will be great if you could follow the patch file naming pattern . _recommendations_ # In AuthenticationFIlter, Instead of doing _instanceof_ on implementation class - _MultiSchemeAuthenticationHandler_ , does it make sense to define an interface say, _ CompositeAuthenticationHandler_ which extends AuthenticationHandler and check against that interface ? This will help others also to write their implementations which could contain multiple handlers. This applies to DelegationTokenAuthenticationFilter and MultiSchemeDelegationTokenAuthenticationHandler also. # Could you please add the documentation for _MultiSchemeAuthenticationHandler_ especially its purpose and the how to configure it ? > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, > hadoop-ldap-auth-v6.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. >
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15200641#comment-15200641 ] Benoy Antony commented on HADOOP-12082: --- Thanks for the new patch, HrishiKesh. _comments_ # In AuthenticationFilter.verifyTokenType, reommend to make the comparison consistent with the existing which does not ignore case. # Create a MiniLdap clas instead of changing MiniKdc. # MultiSchemeAuthenticationHandler - Are schemes Case Sensitive ? Should it be exactly "Digest" ? If not, it's better to ignore case. _nits_ # Unneccessary modification of AuthenticationHandler. _Questions_ # Is there a need to define an Authenticator for the new AuthenticationHandler ? # Can KerberosAuthenticator work with MultiSchemeAuthenticationHandler ? > Support multiple authentication schemes via AuthenticationFilter > > > Key: HADOOP-12082 > URL: https://issues.apache.org/jira/browse/HADOOP-12082 > Project: Hadoop Common > Issue Type: Improvement > Components: security >Affects Versions: 2.6.0 >Reporter: Hrishikesh Gadre >Assignee: Hrishikesh Gadre > Attachments: hadoop-ldap-auth-v2.patch, hadoop-ldap-auth-v3.patch, > hadoop-ldap-auth-v4.patch, hadoop-ldap-auth-v5.patch, hadoop-ldap.patch, > multi-scheme-auth-support-poc.patch > > > The requirement is to support LDAP based authentication scheme via Hadoop > AuthenticationFilter. HADOOP-9054 added a support to plug-in custom > authentication scheme (in addition to Kerberos) via > AltKerberosAuthenticationHandler class. But it is based on selecting the > authentication mechanism based on User-Agent HTTP header which does not > conform to HTTP protocol semantics. > As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] > - HTTP protocol provides a simple challenge-response authentication mechanism > that can be used by a server to challenge a client request and by a client to > provide the necessary authentication information. > - This mechanism is initiated by server sending the 401 (Authenticate) > response with ‘WWW-Authenticate’ header which includes at least one challenge > that indicates the authentication scheme(s) and parameters applicable to the > Request-URI. > - In case server supports multiple authentication schemes, it may return > multiple challenges with a 401 (Authenticate) response, and each challenge > may use a different auth-scheme. > - A user agent MUST choose to use the strongest auth-scheme it understands > and request credentials from the user based upon that challenge. > The existing Hadoop authentication filter implementation supports Kerberos > authentication scheme and uses ‘Negotiate’ as the challenge as part of > ‘WWW-Authenticate’ response header. As per the following documentation, > ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows > NTLM) authentication schemes. > [SPNEGO-based Kerberos and NTLM HTTP > Authentication|http://tools.ietf.org/html/rfc4559] > [Understanding HTTP > Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] > On the other hand for LDAP authentication, typically ‘Basic’ authentication > scheme is used (Note TLS is mandatory with Basic authentication scheme). > http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html > Hence for this feature, the idea would be to provide a custom implementation > of Hadoop AuthenticationHandler and Authenticator interfaces which would > support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via > Basic auth challenge). During the authentication phase, it would send both > the challenges and let client pick the appropriate one. If client responds > with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos > authentication. If client responds with an ‘Authorization’ header tagged with > ‘Basic’ - it will use LDAP authentication. > Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be > configured to use one scheme over the other e.g. > - curl tool supports option to use either Kerberos (via --negotiate flag) or > username/password based authentication (via --basic and -u flags). > - Apache HttpClient library can be configured to use specific authentication > scheme. > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > Typically web browsers automatically choose an authentication scheme based on > a notion of “strength” of security. e.g. take a look at the [design of Chrome > browser for HTTP > authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14714192#comment-14714192 ] Larry McCay commented on HADOOP-12082: -- For whatever reason, I am unable to successfully apply the patch. Only for of the files get modified and none get added. What are you using to apply it? Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: hadoop-ldap-auth-v2.patch, hadoop-ldap.patch, multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712063#comment-14712063 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~lmccay] Any thoughts on the latest patch? Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: hadoop-ldap-auth-v2.patch, hadoop-ldap.patch, multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712093#comment-14712093 ] Larry McCay commented on HADOOP-12082: -- Sorry for the delay in responding - I haven't had a chance to review it in detail. Your description sounds dead on to me. I will take some time tonight to look at the implementation. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: hadoop-ldap-auth-v2.patch, hadoop-ldap.patch, multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[
https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700316#comment-14700316
]
Larry McCay commented on HADOOP-12082:
--
I've applied the patch, built it and given it a quick review.
The implementation seems fine for very specific usecase of HTTP Basic auth
against an LDAP server.
IMO, the coupling of credential scraping: pulling the credentials from the in
coming request and a particular backend implementation like LDAP is unfortunate
and should be reconsidered and refactored in a follow up patch. As I have
described earlier, we should be able to scrape the same credentials from the
request and use them against: LDAP, RDMS or some proprietary auth server. I
think that this refactoring would require separating the current handler for
Ldap into two things:
1. scheme handler
2. authentication handler
{code}
basic.authentication.handler=ldap
{code}
Using the above configuration, we could load all implementations of the
UsernamePasswordAuthenticationHandler interface with the Java ServiceLoader and
interrogate each one for its name. When you find the one that matches the
configured value then it gets used to authenticate the username and password
against its specific backend.
This would allow us to use the same UsernamePasswordAuthenticationHandler for
other ways to get username and password and to use other implementations for
different backends.
The kerberos handler doesn't need this decoupling as far as I can tell.
Unfortunately, I don't think that I am going to be able to leverage this work
for introducing WebSSO flows. Browsers only have the four well known schemes to
work with and will behave according to those schemes upon getting the list of
WWW-Authorization headers. I would love to use this so that we could avoid the
AltKerberosAuthenticationHandler but don't see how.
Support multiple authentication schemes via AuthenticationFilter
Key: HADOOP-12082
URL: https://issues.apache.org/jira/browse/HADOOP-12082
Project: Hadoop Common
Issue Type: Improvement
Components: security
Affects Versions: 2.6.0
Reporter: Hrishikesh Gadre
Assignee: Hrishikesh Gadre
Attachments: hadoop-ldap.patch, multi-scheme-auth-support-poc.patch
The requirement is to support LDAP based authentication scheme via Hadoop
AuthenticationFilter. HADOOP-9054 added a support to plug-in custom
authentication scheme (in addition to Kerberos) via
AltKerberosAuthenticationHandler class. But it is based on selecting the
authentication mechanism based on User-Agent HTTP header which does not
conform to HTTP protocol semantics.
As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html]
- HTTP protocol provides a simple challenge-response authentication mechanism
that can be used by a server to challenge a client request and by a client to
provide the necessary authentication information.
- This mechanism is initiated by server sending the 401 (Authenticate)
response with ‘WWW-Authenticate’ header which includes at least one challenge
that indicates the authentication scheme(s) and parameters applicable to the
Request-URI.
- In case server supports multiple authentication schemes, it may return
multiple challenges with a 401 (Authenticate) response, and each challenge
may use a different auth-scheme.
- A user agent MUST choose to use the strongest auth-scheme it understands
and request credentials from the user based upon that challenge.
The existing Hadoop authentication filter implementation supports Kerberos
authentication scheme and uses ‘Negotiate’ as the challenge as part of
‘WWW-Authenticate’ response header. As per the following documentation,
‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows
NTLM) authentication schemes.
[SPNEGO-based Kerberos and NTLM HTTP
Authentication|http://tools.ietf.org/html/rfc4559]
[Understanding HTTP
Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx]
On the other hand for LDAP authentication, typically ‘Basic’ authentication
scheme is used (Note TLS is mandatory with Basic authentication scheme).
http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html
Hence for this feature, the idea would be to provide a custom implementation
of Hadoop AuthenticationHandler and Authenticator interfaces which would
support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via
Basic auth challenge). During the authentication phase, it would send both
the challenges and let client pick the appropriate one. If client responds
with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos
authentication. If client responds with an
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14698056#comment-14698056 ] Larry McCay commented on HADOOP-12082: -- Hi [~hgadre] - Thank you for reaching out - I look forward to reviewing it! I will try and carve out some time this weekend to take a look at the patch in detail. The service loader pluggability that I mentioned before would be a Java ServiceLoader mechanism to load a set of classes that implement a given interface. If you provide a getName() as part of that interface then you can iterate over the set to pull out the specific configured handler. What I am trying to do is provide a decoupling of the challenge type and the actual backend authentication type. So, if we could indicate that HTTP Basic auth was accepted through the challenge, we could have the backend authenticate against the preferred user store: LDAP, RDBMS, etc. Rather than tying HTTP Basic auth the LDAP alone. The easiest way forward - I think - is to provide an implementation with discrete handlers for the challenges. We can then refactor that to support multiple backends. I would get your concrete usecases met with an implementation that we can move forward and maintain backward compatibility for without slowing progress. Adding pluggability later shouldn't be too hard and having tests for the initial functionality would help that work. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: hadoop-ldap.patch, multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme.
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642604#comment-14642604 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~lmccay] I have been traveling for last few weeks. Expect a patch in next few days. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1462#comment-1462 ] Shay Rojansky commented on HADOOP-12082: Btw, if you're looking at reworking authentication it may be a good idea to look at SASL. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14629959#comment-14629959 ] Larry McCay commented on HADOOP-12082: -- Hi [~hgadre] - curious about the status of this work. I think that it adds value and would like to see it move forward. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604679#comment-14604679 ] Shay Rojansky commented on HADOOP-12082: +1 on this. An additional use case is accessing the Hadoop web UIs from outside the corporate infrastructure, e.g. from home over a VPN. The home computer isn't in the Kerberos realm so can't log in. With the current AltKerberosAuthenticationHandler scheme it's impossible for internal browsers to use SPNEGO/Kerberos and for external browsers to fall back to LDAP. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604690#comment-14604690 ] Larry McCay commented on HADOOP-12082: -- One thing that I am curious about - we are describing a Basic challenge as representing LDAP - however, UIs generally want to present a form-based login page rather than use the browser Basic login dialog. How do we add this level of fidelity. Coming back to the server side - there really isn't anything about Basic that requires it to be LDAP - of course this is probably most common. I have been mulling around the thought of having the auth mechanisms be pluggable using a combination of ServiceLoader and names. We would add (probably just marker) interfaces to represent Negotiate, Basic, etc. Use ServiceLoader to get all the Negotiate implementations and interrogate each one for a getName() that matches the configured name for the Negotiate impl. This would allow us to overload Basic with LDAP, JDBC, etc. Likewise, if we were to consider a Bearer token impl, we could overload Bearer with SAML, JWT, etc - though we may be able to derive the type of the Bearer token through the request. For instance, OAuth JWT+Bearer grant type would be set to something like grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer. Technically, GSS based Negotiate doesn't have to be limited to SPNEGO either. Doubtful that we would need to overload that any time soon though. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604693#comment-14604693 ] Larry McCay commented on HADOOP-12082: -- To be clear, I don't think that those considerations should block progress here - they could be discussed and handled in a follow up jira. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604793#comment-14604793 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~lmccay] Technically, GSS based Negotiate doesn't have to be limited to SPNEGO either. Interesting. As per my understanding (based on the articles below), that is not the case. Can you please take a look and comment? [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14604834#comment-14604834 ] Larry McCay commented on HADOOP-12082: -- GSSAPI is supposedly a generic security API. That is just noise though. We won't need anything other than kerberos for negotiate. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Assignee: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581051#comment-14581051 ] Larry McCay commented on HADOOP-12082: -- I was aware of that but didn't think it would be picked up by browsers or other clients that were aware of this multiple scheme protocol. That would be ideal. Adding another handler would be easy enough - I think that we should make it more dynamic/configurable though. There are multiple types of Bearer tokens for instance: JWT, SAML, OAuth, etc. I'd be happy to help out with additional handlers to plugin if that is of interest. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581034#comment-14581034 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~lmccay] It's a shame that there doesn't seem to be a way to present a Bearer token authentication scheme. Not really. HTTP specs support Bearer token authentication. Please take a look at http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml I think we would need to add another AuthenticationHandler implementing Bearer tokens and add it to MultiSchemeAuthenticationHandler (Please see the attached file multi-scheme-auth-support-poc.patch). Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581007#comment-14581007 ] Larry McCay commented on HADOOP-12082: -- I like this approach! One benefit that I can see over AltKerberosAuthenticationHandler is that I've encountered non-browser user agents that were calling the JMX servlet and they weren't capable of NEGOTIATE or the custom handler - like a redirect to a login page. This would at least allow them to use Basic. I don't think that is actually a possibility for what I saw but could maybe be added. It's a shame that there doesn't seem to be a way to present a Bearer token authentication scheme. I wonder if we could add something like Bearer+JWT to the server side and at then clients that are aware of it can take advantagethis needs to be thought through more but feels like something that could add value. Question: AltKerberosAuthenticationProvider seems to require that kerberos be enabled for HTTP - does this implementation also require kerberos? While it being enabled does make sense - there are folks that want to provide authenticated access to the UIs for deployments without SPNEGO turned on too. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580951#comment-14580951 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~asuresh] Considering the fact that browsers automatically always pick the strongest scheme, is there anyway to allow that certain clients/browsers over-ride this and pick LDAP over Kerb ? It looks like browsers are able to detect the fact that - server supports multiple authentication schemes (viz. Basic and Negotiate) - the kerberos credentials are missing on the client side Hence the browser pops-up a dialog box for an user to enter username/password. Upon entering correct credentials, the website opens as expected. If wrong credentials are supplied, the server throws 403 error (as expected). I have tested this on three different browsers - Safari, Chrome Firefox. As per my understanding - the strongest security scheme is chosen based on available information. e.g. if a browser already has access to kerberos credentials, it will not ask for username/password since kerberos auth scheme is more secure than basic auth. Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580897#comment-14580897 ] Arun Suresh commented on HADOOP-12082: -- [~hgadre], thanks for opening this. One specific usecase of the AltKerberosHandler was to allow clients (browsers) not within the security infrastructure to talk to hadoop. Considering the fact that browsers automatically always pick the strongest scheme, is there anyway to allow that certain clients/browsers over-ride this and pick LDAP over Kerb ? Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
[ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14581063#comment-14581063 ] Hrishikesh Gadre commented on HADOOP-12082: --- [~lmccay] AltKerberosAuthenticationProvider seems to require that kerberos be enabled for HTTP - does this implementation also require kerberos? While it being enabled does make sense - there are folks that want to provide authenticated access to the UIs for deployments without SPNEGO turned on too. I don't think so. The AuthenticationFilter implementation is generic enough to allow specifying custom handlers. So it should be straightforward to configure a Auth handler implementing a scheme different than Kerberos. (Note for our use-case we do want to support LDAP and Kerberos simultaneously). Support multiple authentication schemes via AuthenticationFilter Key: HADOOP-12082 URL: https://issues.apache.org/jira/browse/HADOOP-12082 Project: Hadoop Common Issue Type: Improvement Components: security Affects Versions: 2.6.0 Reporter: Hrishikesh Gadre Attachments: multi-scheme-auth-support-poc.patch The requirement is to support LDAP based authentication scheme via Hadoop AuthenticationFilter. HADOOP-9054 added a support to plug-in custom authentication scheme (in addition to Kerberos) via AltKerberosAuthenticationHandler class. But it is based on selecting the authentication mechanism based on User-Agent HTTP header which does not conform to HTTP protocol semantics. As per [RFC-2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] - HTTP protocol provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request and by a client to provide the necessary authentication information. - This mechanism is initiated by server sending the 401 (Authenticate) response with ‘WWW-Authenticate’ header which includes at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. - In case server supports multiple authentication schemes, it may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different auth-scheme. - A user agent MUST choose to use the strongest auth-scheme it understands and request credentials from the user based upon that challenge. The existing Hadoop authentication filter implementation supports Kerberos authentication scheme and uses ‘Negotiate’ as the challenge as part of ‘WWW-Authenticate’ response header. As per the following documentation, ‘Negotiate’ challenge scheme is only applicable to Kerberos (and Windows NTLM) authentication schemes. [SPNEGO-based Kerberos and NTLM HTTP Authentication|http://tools.ietf.org/html/rfc4559] [Understanding HTTP Authentication|https://msdn.microsoft.com/en-us/library/ms789031%28v=vs.110%29.aspx] On the other hand for LDAP authentication, typically ‘Basic’ authentication scheme is used (Note TLS is mandatory with Basic authentication scheme). http://httpd.apache.org/docs/trunk/mod/mod_authnz_ldap.html Hence for this feature, the idea would be to provide a custom implementation of Hadoop AuthenticationHandler and Authenticator interfaces which would support both schemes - Kerberos (via Negotiate auth challenge) and LDAP (via Basic auth challenge). During the authentication phase, it would send both the challenges and let client pick the appropriate one. If client responds with an ‘Authorization’ header tagged with ‘Negotiate’ - it will use Kerberos authentication. If client responds with an ‘Authorization’ header tagged with ‘Basic’ - it will use LDAP authentication. Note - some HTTP clients (e.g. curl or Apache Http Java client) need to be configured to use one scheme over the other e.g. - curl tool supports option to use either Kerberos (via --negotiate flag) or username/password based authentication (via --basic and -u flags). - Apache HttpClient library can be configured to use specific authentication scheme. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html Typically web browsers automatically choose an authentication scheme based on a notion of “strength” of security. e.g. take a look at the [design of Chrome browser for HTTP authentication|https://www.chromium.org/developers/design-documents/http-authentication] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
