That’s perfect — sorry I didn’t get back to you.
> On Apr 4, 2016, at 8:58 AM, Josh Elser <[email protected]> wrote:
>
> 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
>>>
>>>
