calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: Thoughts on Avatica user auth?
Date Mon, 04 Apr 2016 15:58:29 GMT
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<josh.elser@gmail.com> 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
>>
>>

Mime
View raw message