[jira] [Commented] (CALCITE-643) User authentication for avatica clients

["Josh Elser (JIRA)" <ji...@apache.org>]

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

Josh Elser commented on CALCITE-643:
------------------------------------

Started thinking again about how this would work. We have the patch on CALCITE-1025 which does some HTTP basic authentication, but where else do we want to go? Off the top of my head, I can see authentication broken down into two pieces:

# Avatica-controlled authentication
# Delegated authentication to the wrapped JDBC driver

h3. Avatica-controlled auth

There are two things that have been talked about for authentication:

# a simple username/password based system
# Kerberos support

Basic authentication is one way to achieve the first over HTTP, but it seems like using Digest is a better building block for a secure system (http://talks.codegram.com/http-authentication-methods#/intro was a nice intro).

I had been hoping there was some support for SASL over HTTP, but it seems like that isn't "a thing". SPNEGO is which uses the HTTP negotiate functionality. There seems to be some support could be borrowed from Hadoop's codebase which they use to secure their web APIs (https://github.com/apache/hadoop/tree/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication).

h3. delegation approach

At first glance, I thought this would be relatively straightforward. We just need to protect the data on the wire from prying eyes and then everything is fine (the "real" JDBC connection would do the authentication for us). I think there is still a concern of how confident we are that a user who has some valid connectionId actually owned the connection (e.g. replay attack, MITM attack). Maybe there is an approach we could take to generate some kind of "security token" upon opening a connection that every request after for that connection would require (trivially, a cookie with some secret?). I'm a little fuzzy on what exactly this would entail -- need to compare to what other projects do (and what is acceptable).

h3. other thoughts

What about encryption? Do we want to require TLS to be a part of the secure authentication picture? HTTP digest aims to do secure authentication without the need for a secure transport which would be nice. I think that would be a nice target to move towards, but TLS integration is probably inevitable so as it is. 

> User authentication for avatica clients
> ---------------------------------------
>
>                 Key: CALCITE-643
>                 URL: https://issues.apache.org/jira/browse/CALCITE-643
>             Project: Calcite
>          Issue Type: Improvement
>          Components: avatica
>            Reporter: Nick Dimiduk
>            Assignee: Julian Hyde
>              Labels: avatica
>
> Avatica client API needs a means for accepting a users authorization status, passing it to the server, and the server to act on that users behalf when interacting with the underlying connection.



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