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
