I spent some time hacking on this today.
First off, this is only relevant for HTTP Basic authentication as to
perform this kind of authentication check against the underlying
database, the password needs to be in a recoverable form (e.g.
base64/obfuscated). If this isn't the case, then the Avatica server
cannot check the password against the backend database.
Along the same lines, trying to implement HTTP Digest authentication
against the backend database is impossible because the server doesn't
have access to the real password.
This entire experiment has made me question what we're really trying to
solve here. The requested scenario from Samarth and Julian are
ultimately just acting as a fail-fast and sending an HTTP 401 or 403
response (instead of Avatica's general ErrorResponse). I'm feeling like
this might need to go back to the drawing board and lay out some clear
requirements for why Avatica should provide user-password authentication
and benefit Avatica would be providing to the client that isn't already
in place.
Josh Elser wrote:
So it looks like Jetty's JDBCLoginService[1] simply takes configuration
to read tables from a given JDBC driver to extract users+passwords and
roles for those users. This doesn't actually hook into the database's
authentication system. Best as I've been able to find, there is no
generic API provided by JDBC which Avatica could leverage.
Maybe it's possible to create our own LoginService (so we can use
Jetty's built-in security support) which instantiates a Connection with
the Avatica client's user/password. I'm worried about the overhead of
repeatedly doing this, though.
[1] https://wiki.eclipse.org/Jetty/Tutorial/Realms#JDBCLoginService
Josh Elser wrote:
Actually, it looks like Jetty might provide some implementation which
defers to JDBC for authentication. Let me look into that.
Josh Elser wrote:
.. but what mechanism could Avatica use to do this generically? Is there
a means to verify some credentials without trying to instantiate a
java.sql.Connection with the given user/password?
Julian Hyde wrote:
I agree with Sarnath about complexity. If I’m a user logging into
database X there’s no way you could persuade me that I need to have a
set of credentials for the network hop and another for the database.
If the database uses basic authentication user name ‘scott’ password
‘tiger’, and the person who configured the Avatica server said use
basic authentication, then Avatica should use the same credentials.
Yes, it’s not very secure, but hey, that’s basic authentication.
Julian
On Mar 29, 2016, at 6:49 AM, Josh Elser<[email protected]> wrote:
Just to make sure it's clear, the credentials would have to be
duplicated elsewhere presently (e.g. in a properties file that Jetty
can read). Maybe there's a JDBC API that the Avatica server could
hook directly into to avoid such credential duplication?
Sarnath wrote:
The extra pair adds additional complexity... I think it is better
to go
with underlying database creds.. Or better provide a hook to
interested
users who want separate creds...
