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 >
