On Tue, May 16, 2017 at 1:28 AM, F21 <f21.gro...@gmail.com> wrote:
Hey guys,
I recently received a request to add authentication to the Go Avatica
driver.
I am currently investigating ways to implement this. One of the
limitations
of the Go database/sql package is that all configuration options
need to be
passed in through the connection string (DSN). For the Go driver, I
currently have the following:
http://address:port[/schema][?parameter1=value&...parameterN=value]
Parts in between "[" and "]" are optional. Valid parameters are
location,
maxRowsTotal, frameMaxSize and transactionIsolation.
Does the Java Avatica thin client support HTTP Basic and Digest
Authentication? After reading the docs on Security[0], I get the
impression
that it is only useful for gating access to the Avatica server. If
using
HTTP Basic and Digest auth, is the role required in the client
request? If
so, what is the HTTP header for sending the role to the server? I am
also
trying to assess to see if HTTP Basic and Digest authentication is
worth
implementing.
It does support Basic and Digest auth, but it's not the most useful in
its current form (IMO). The only authentication "database" it can use
are the flat-files:
e.g. https://wiki.eclipse.org/Jetty/Tutorial/Realms under
HashLoginService
We _could_ consider connectors to other authentication systems, but,
being lazy and all, I'd prefer to use some proxy in from of Avatica
that does authentication, authorization, encryption, and
load-balancing for us :)
I think SPNEGO/Kerberos auth is probably the best form of
authentication and
is used by Phoenix/HBase and quite a lot of other database backends.
However, the downside is that there is no usable pure-go
SPNEGO/Kerberos
library as the only one that exists is still lacking a lot of features.
There is a fork of jmckaskill/gokerb[1] which is more up-to-date but
doesn't
look to be actively maintained.
The only option to implement SPNEGO at this point is to use a
library that
wraps libgssapi, for example apcera/gssapi[2]. However, the
downsides of
using something like this is that it rely on cgo, which makes it
harder to
debug and will make the Go driver unusable on Windows.
Kerberos/SPNEGO is definitely much nicer for organizations to use
(centralized user access via the KDC or Active Directory), but that's
a shame it comes with other caveats from the Go side.
I also noticed that the JDBC driver has support for user and password
parameters which are passed directly to the underlying server. If I
want to
build support for this, how should the user and password be sent to
avatica?
Should I include a `user` and `password` key in the info map within
OpenConnectionRequest[3]?
There are essentially two sets of "users": one for the database and
one for Avatica's authentication. "user" and "password" are passed
directly into the database Avatica is wrapping.
Whereas, the "avatica_user" and "avatica_password" are just extracted
and used for the HTTP authentication with the Avatica server. These
are primarily just something for the Java client to use read
configuration from. The properties are extracted from the JDBC url,
and used by the Java client to set up the HTTP request to the Avatica
server.
You could follow the same approach with the Go driver (or come up with
your own). It's up to you!
Cheers,
Francis
[0]
http://calcite.apache.org/avatica/docs/security.html#http-basic-authentication
[1] https://github.com/jgcallero/gokerb
[2] https://github.com/apcera/gssapi
[3]
http://calcite.apache.org/avatica/docs/protobuf_reference.html#openconnectionrequest
