Hudson commented on HADOOP-12082:
SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #10636 (See
HADOOP-12082 Support multiple authentication schemes via (benoy: rev
* (edit) hadoop-project/pom.xml
* (edit) hadoop-common-project/hadoop-auth/pom.xml
* (edit) hadoop-common-project/hadoop-auth/src/site/markdown/Configuration.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-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,
> 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
> - 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
> [Understanding HTTP
> On the other hand for LDAP authentication, typically ‘Basic’ authentication
> scheme is used (Note TLS is mandatory with Basic authentication scheme).
> 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
> 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
This message was sent by Atlassian JIRA
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org