You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Josh Elser <jo...@gmail.com> on 2016/03/28 18:05:03 UTC
Thoughts on Avatica user auth?
Hi all,
I was hacking on https://issues.apache.org/jira/browse/CALCITE-1173 over
the weekend to add HTTP Basic and Digest auth to Avatica (now that I
laid a lot of groundwork in the SPNEGO/Kerberos task).
I'm wondering how best to handle "Avatica authentication" and "Database
authentication".
Presently, when the user provides a user/password when creating the
Avatica JDBC driver, this is passed directly to the Avatica server, and
is passed along to the "real" JDBC driver (the one talking to the actual
"database"). Should Avatica maintain a separate user/password property
pair for Avatica-centric authentication?
Pros:
* Avatica can provide further control over allowed users than the
database alone (e.g. a valid db user may not be allowed to use Avatica).
Cons:
* Users must provide two sets of credentials (e.g. user/password and
avatica_user/avatica_password)) to differentiate between what is for
Avatica and what is for the "real" JDBC driver.
I'm not sure which is the better approach to take. The latter definitely
has the flexibility, but I'm wondering if it would be confusing with
other tools (since it's not following "normal JDBC conventions"). Either
approach is relatively simple to implement in Avatica, so that's not a
big decision-factor.
- Josh
Re: Thoughts on Avatica user auth?
Posted by Julian Hyde <jh...@apache.org>.
That’s perfect — sorry I didn’t get back to you.
> On Apr 4, 2016, at 8:58 AM, Josh Elser <jo...@gmail.com> 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<jo...@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
>>>
>>>
Re: Thoughts on Avatica user auth?
Posted by Josh Elser <jo...@gmail.com>.
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<jo...@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
>>
>>
Re: Thoughts on Avatica user auth?
Posted by Josh Elser <jo...@gmail.com>.
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<jo...@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
>
>
Re: Thoughts on Avatica user auth?
Posted by Julian Hyde <jh...@apache.org>.
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 <jo...@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
Re: Thoughts on Avatica user auth?
Posted by Josh Elser <jo...@gmail.com>.
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
Re: Thoughts on Avatica user auth?
Posted by Josh Elser <jo...@gmail.com>.
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<jo...@gmail.com> 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...
>>>>>>
>>>>
Re: Thoughts on Avatica user auth?
Posted by Josh Elser <jo...@gmail.com>.
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<jo...@gmail.com> 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...
>>>>>
>>>
Re: Thoughts on Avatica user auth?
Posted by Josh Elser <jo...@gmail.com>.
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<jo...@gmail.com> 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...
>>>>
>>
Re: Thoughts on Avatica user auth?
Posted by Josh Elser <jo...@gmail.com>.
.. 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<jo...@gmail.com> 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...
>>>
>
Re: Thoughts on Avatica user auth?
Posted by Julian Hyde <jh...@apache.org>.
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 <jo...@gmail.com> 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...
>>
Re: Thoughts on Avatica user auth?
Posted by Josh Elser <jo...@gmail.com>.
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...
>
Re: Thoughts on Avatica user auth?
Posted by Sarnath <st...@gmail.com>.
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...
Re: Thoughts on Avatica user auth?
Posted by Josh Elser <jo...@gmail.com>.
Ended up putting together a solution that used "avatica_user" and
"avatica_password" to complement "user" and "password".
If anyone is interested: https://github.com/apache/calcite/pull/217
Josh Elser wrote:
> Hi all,
>
> I was hacking on https://issues.apache.org/jira/browse/CALCITE-1173 over
> the weekend to add HTTP Basic and Digest auth to Avatica (now that I
> laid a lot of groundwork in the SPNEGO/Kerberos task).
>
> I'm wondering how best to handle "Avatica authentication" and "Database
> authentication".
>
> Presently, when the user provides a user/password when creating the
> Avatica JDBC driver, this is passed directly to the Avatica server, and
> is passed along to the "real" JDBC driver (the one talking to the actual
> "database"). Should Avatica maintain a separate user/password property
> pair for Avatica-centric authentication?
>
> Pros:
> * Avatica can provide further control over allowed users than the
> database alone (e.g. a valid db user may not be allowed to use Avatica).
>
> Cons:
> * Users must provide two sets of credentials (e.g. user/password and
> avatica_user/avatica_password)) to differentiate between what is for
> Avatica and what is for the "real" JDBC driver.
>
> I'm not sure which is the better approach to take. The latter definitely
> has the flexibility, but I'm wondering if it would be confusing with
> other tools (since it's not following "normal JDBC conventions"). Either
> approach is relatively simple to implement in Avatica, so that's not a
> big decision-factor.
>
> - Josh