[
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)
