hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry McCay (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-12082) Support multiple authentication schemes via AuthenticationFilter
Date Mon, 17 Aug 2015 22:12:46 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-12082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ‘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)

Mime
View raw message