[jira] [Comment Edited] (CALCITE-1025) Add support for HTTP Basic auth (for proxies) in Avatica HTTP Client

["Kevin Minder (JIRA)" <ji...@apache.org>]

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

Kevin Minder edited comment on CALCITE-1025 at 2/15/16 3:24 PM:
----------------------------------------------------------------

HTTP BasicAuth isn't always great for proxies.  There are basically two types of proxy models relative to the handling of identity:
1. Transparent Proxy - In this case the HTTP BasicAuth challenge and response would flow through the proxy and things would be fine.
2. Trusted Proxy - In this case the expectation is that the proxy itself does the authentication and will only send the authenticated identity downstream.  In this case HTTP BasicAuth doesn't work very will.  You are better off with something like SSL mutual authentication to establish trust between the proxy and the downstream server and then have the authenticated identity propagated via a HTTP header.  Unfortunately there is no standard here.  You could "hijack" the HTTP Authorization header and user a "dummy" value for the password or use some other arbitrary header (e.g. CALCITE_USER).  Since this should probably only work over SSL it would not even need to be encrypted.
Not after pointing this out, it probably makes sense to support both things.  The last thing I want to point out is the existence of Hadoop's hadoop-auth module (https://hadoop.apache.org/docs/r2.7.2/hadoop-auth/).  At least brief consideration should be given to supporting this as it creates a natural alignment with how many of the other Hadoop ecosystem components handle authentication (including proxy user support).


was (Author: kminder):
HTTP BasicAuth isn't always great for proxies.  There are basically two types of proxy models:
1. Transparent Proxy - In this case the HTTP BasicAuth challenge and response would flow through the proxy and things would be fine.
2. Trusted Proxy - In this case the expectation is that the proxy itself does the authentication and will only send the authenticated identity downstream.  In this case HTTP BasicAuth doesn't work very will.  You are better off with something like SSL mutual authentication to establish trust between the proxy and the downstream server and then have the authenticated identity propagated via a HTTP header.  Unfortunately there is no standard here.  You could "hijack" the HTTP Authorization header and user a "dummy" value for the password or use some other arbitrary header (e.g. CALCITE_USER).  Since this should probably only work over SSL it would not even need to be encrypted.
Not after pointing this out, it probably makes sense to support both things.  The last thing I want to point out is the existence of Hadoop's hadoop-auth module (https://hadoop.apache.org/docs/r2.7.2/hadoop-auth/).  At least brief consideration should be given to supporting this as it creates a natural alignment with how many of the other Hadoop ecosystem components handle authentication (including proxy user support).

> Add support for HTTP Basic auth (for proxies) in Avatica HTTP Client
> --------------------------------------------------------------------
>
>                 Key: CALCITE-1025
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1025
>             Project: Calcite
>          Issue Type: Improvement
>          Components: avatica
>            Reporter: Phillip Rhodes
>            Assignee: Phillip Rhodes
>         Attachments: AvaticaConnection.patch, Driver.patch, RemoteService.patch, http_auth_patch.patch, patch_against_1.2.0.patch
>
>
> Avatica serves as the base for the Phoenix "thin" JDBC driver, and supports a JSON over HTTP protocol.  Being that it is HTTP, it would be desirable to support standard HTTP mechanisms like HTTP BASIC authentication, which is required by some proxy servers (for example, Knox).
> In particular, I've been working on deploying Phoenix behind Knox with Knox mediating JDBC access using the "thin" driver based on Avatica.  In order to make this work, I had to make a small change to Avatica in order to take the supplied credentials and construct an Authorization header, and add it to the HTTP request.  
> I have made this change and verified that it works, and would like to propose merging it into the Avatica source.   I have two versions, one made against HEAD and another which is a backport to an older version of Avatica (turns out this was needed for the specific environment we were deploying in).
> It is a fairly small change, totaling about 10-15 lines of code, and - as far as I can tell - should be totally non-invasive to existing users of Avatica.   Basically I just add the HTTP Authorization header IF a username/password combo is present, and do nothing otherwise.  If it is desired, we could also wrap this code in a parameter based on a query string parameter or something.  Maybe "enableProxyAuth=true" or something along those lines.
> I'll attach the actual modified code shortly, but in the meantime wanted to start a discussion around this proposed change.  I have run this by some people inside HortonWorks and they are in favor of implementing this so that it can become part of HDP.   Being able to use Knox (or, in theory, any other proxy server) to mediate JDBC access to Phoenix seems to be a desirable thing.  Thoughts?  



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