I've gone ahead and merged in what I have written. I made sure the
documentation for the password-auth Avatica-provided auth were clearly
marked as *only* intended for use without JDBC-authentication in the
picture.
As such, if there are issues with this approach as it exists, we can
revert if necessary, but I don't think there are. There is definitely
room for improvement and would be happy to entertain discussion about
what a phase 2 of this would look like.
Josh Elser wrote:
Let me say this again (maybe a bit more bluntly): yes, it's stupid to
authenticate the same credentials twice :). We're not in disagreement
there. That's what I meant when I said "HTTP-level authentication [only]
adds some value is when we are *not* using the database for any user
authentication"
Making HTTP-level authentication which talks directly to the database is
a possibility, but, best as I can tell, not from JDBC. I think this
would have a few issues implementing it. And, in the end, not getting us
anything.
BTW, I've updated https://github.com/apache/calcite/pull/217 with this
approach, docs too. The short of it is that Avatica can provide its own
username/password, but this is not a substitute for the traditional JDBC
user/password properties.
Does that make sense?
Julian Hyde wrote:
But I can’t think of a single ODBC or JDBC driver I’ve used that
requires me to provide parameters to authenticate both the transport
AND the underlying database. How do they all manage it if we can’t?
Can we not have it talk to an authentication SPI that by default talks
to the database?
I don’t know what I’m talking about but I’m playing the dumb user and
I don’t see why implementation details such as this should be poking out.
Julian
On Mar 29, 2016, at 1:50 PM, Josh Elser<[email protected]> wrote:
Josh Elser wrote:
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.
Chewing on this point some more: applying HTTP-level authentication
which delegates to the database seems wholly duplicative to me. The
only relevant scenario I can come up with for HTTP-level
authentication which adds some value is when we are *not* using the
database for any user authentication.
As such, I'm leaning towards Avatica acting as a "database proxy" (in
the sense of something like Apache Knox's gateway would do, how we
got here in the first place), in which it *can* require its own set
of credentials for a user to access it that are disjoint from the
database.
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
