You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by Sudheesh Katkam <sk...@maprtech.com> on 2016/02/19 22:49:28 UTC
[DISCUSS] New Feature: Drill Client Impersonation
Hey y’all,
I plan to work on DRILL-4281 <https://issues.apache.org/jira/browse/DRILL-4281>: support for inbound/client impersonation. Please review the design document <https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>, which is open for comments. There is also a link to proof-of-concept (slightly hacky).
Thank you,
Sudheesh
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Keys Botzum <kb...@maprtech.com>.
Connection level identity setting is only viable if the scalability concerns I raised in the doc and Jacques indirectly raised are addressed.
Historically DB connections have been so expensive that most applications created pools of connections and reused them across users. That model doesn't work if each connection is tied to a single user. That's why the typical implementation has provided for changing the identity on an existing connection.
Now, if the Drill connection is a very lightweight object (possibly mapping to a single heavier weight hidden process level object), then tying identity to the connection is fine. I don't know enough about the Drill architecture to comment on that but I think a good rule of thumb would be "is it reasonable to keep 50+ Drill connections open where each has a different user identity?" If the answer is no, then the design needs to consider the scale. I'll also add that much further in the future if/when Drill takes on more operational types of access that 50 connections will rise to a much larger number.
Keys
_______________________________
Keys Botzum
Senior Principal Technologist
kbotzum@maprtech.com <ma...@maprtech.com>
443-718-0098
MapR Technologies
http://www.mapr.com <http://www.mapr.com/>
> On Feb 22, 2016, at 4:36 PM, Neeraja Rentachintala <nr...@maprtech.com> wrote:
>
> It seems to me that for phase 1, we should only have this as connection
> level property and have the list of proxy users as a static bootstrap
> option. Drill doesn't have a very granular privilege model other than
> admins vs non-admins, so till then exposing this via system options seems
> like a risk to me from a security standpoint.
>
> -Neeraja
>
> On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam <sk...@maprtech.com>
> wrote:
>
>> “… when creating this connection, as part of the connection properties
>> (JDBC, C++ Client), the application passes the end user’s identity (e.g.
>> username) …”
>>
>> I had written the change user as a session option as part of the
>> enhancement only, where you’ve pointed out a better way. I addressed your
>> comments on the doc.
>>
>> Thank you,
>> Sudheesh
>>
>>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
>>>
>>> Maybe I misunderstood the design document.
>>>
>>> I thought this was how the user would be changed: "Provide a way to
>> change
>>> the user after the connection is made (details) through a session option"
>>>
>>> Did I miss something?
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
>>> nrentachintala@maprtech.com> wrote:
>>>
>>>> Jacques,
>>>> I think the current proposal by Sudheesh is an API level change to pass
>>>> this additional end user id during the connection establishment.
>>>> Can you elaborate what you mean by random query.
>>>>
>>>> -Neeraja
>>>>
>>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
>>>> wrote:
>>>>
>>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>>>> documentation,
>>>>> they expose this at the API level rather than through a random query. I
>>>>> think we should probably model after that rather than invent a new
>>>>> mechanism. This also means we can avoid things like query parsing,
>>>>> execution roundtrip, query profiles, etc to provide this functionality.
>>>>>
>>>>> See here:
>>>>>
>>>>>
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>>>>>
>>>>> --
>>>>> Jacques Nadeau
>>>>> CTO and Co-Founder, Dremio
>>>>>
>>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
>>>> wrote:
>>>>>
>>>>>> This is a great feature to add to Drill and I'm excited to see design
>>>> on
>>>>>> it starting.
>>>>>>
>>>>>> The ability for an intermediate server that is likely already
>>>>>> authenticating end users, to send end user identity down to Drill adds
>>>> a
>>>>>> key element into an end to end secure design by enabling Drill and the
>>>>> back
>>>>>> end systems to see the real user and thus perform meaningful
>>>>> authorization.
>>>>>>
>>>>>> Back when I was building many JEE applications I know the DBAs where
>>>> very
>>>>>> frustrated that the application servers blinded them to the identity
>> of
>>>>> the
>>>>>> end user accessing important corporate data. When JEE application
>>>> servers
>>>>>> and databases finally added the ability to impersonate that addressed
>> a
>>>>> lot
>>>>>> of security concerns. Of course this isn't a perfect solution and I'm
>>>>> sure
>>>>>> others will recognize that in some scenarios impersonation isn't the
>>>> best
>>>>>> approach, but having that as an option in Drill is very valuable.
>>>>>>
>>>>>> Keys
>>>>>> _______________________________
>>>>>> Keys Botzum
>>>>>> Senior Principal Technologist
>>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>>>> 443-718-0098
>>>>>> MapR Technologies
>>>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hey y’all,
>>>>>>>
>>>>>>> I plan to work on DRILL-4281 <
>>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>>>> inbound/client impersonation. Please review the design document <
>>>>>>
>>>>>
>>>>
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
>>>>>> ,
>>>>>> which is open for comments. There is also a link to proof-of-concept
>>>>>> (slightly hacky).
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Sudheesh
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Keys Botzum <kb...@maprtech.com>.
Connection level identity setting is only viable if the scalability concerns I raised in the doc and Jacques indirectly raised are addressed.
Historically DB connections have been so expensive that most applications created pools of connections and reused them across users. That model doesn't work if each connection is tied to a single user. That's why the typical implementation has provided for changing the identity on an existing connection.
Now, if the Drill connection is a very lightweight object (possibly mapping to a single heavier weight hidden process level object), then tying identity to the connection is fine. I don't know enough about the Drill architecture to comment on that but I think a good rule of thumb would be "is it reasonable to keep 50+ Drill connections open where each has a different user identity?" If the answer is no, then the design needs to consider the scale. I'll also add that much further in the future if/when Drill takes on more operational types of access that 50 connections will rise to a much larger number.
Keys
_______________________________
Keys Botzum
Senior Principal Technologist
kbotzum@maprtech.com <ma...@maprtech.com>
443-718-0098
MapR Technologies
http://www.mapr.com <http://www.mapr.com/>
> On Feb 22, 2016, at 4:36 PM, Neeraja Rentachintala <nr...@maprtech.com> wrote:
>
> It seems to me that for phase 1, we should only have this as connection
> level property and have the list of proxy users as a static bootstrap
> option. Drill doesn't have a very granular privilege model other than
> admins vs non-admins, so till then exposing this via system options seems
> like a risk to me from a security standpoint.
>
> -Neeraja
>
> On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam <sk...@maprtech.com>
> wrote:
>
>> “… when creating this connection, as part of the connection properties
>> (JDBC, C++ Client), the application passes the end user’s identity (e.g.
>> username) …”
>>
>> I had written the change user as a session option as part of the
>> enhancement only, where you’ve pointed out a better way. I addressed your
>> comments on the doc.
>>
>> Thank you,
>> Sudheesh
>>
>>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
>>>
>>> Maybe I misunderstood the design document.
>>>
>>> I thought this was how the user would be changed: "Provide a way to
>> change
>>> the user after the connection is made (details) through a session option"
>>>
>>> Did I miss something?
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
>>> nrentachintala@maprtech.com> wrote:
>>>
>>>> Jacques,
>>>> I think the current proposal by Sudheesh is an API level change to pass
>>>> this additional end user id during the connection establishment.
>>>> Can you elaborate what you mean by random query.
>>>>
>>>> -Neeraja
>>>>
>>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
>>>> wrote:
>>>>
>>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>>>> documentation,
>>>>> they expose this at the API level rather than through a random query. I
>>>>> think we should probably model after that rather than invent a new
>>>>> mechanism. This also means we can avoid things like query parsing,
>>>>> execution roundtrip, query profiles, etc to provide this functionality.
>>>>>
>>>>> See here:
>>>>>
>>>>>
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>>>>>
>>>>> --
>>>>> Jacques Nadeau
>>>>> CTO and Co-Founder, Dremio
>>>>>
>>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
>>>> wrote:
>>>>>
>>>>>> This is a great feature to add to Drill and I'm excited to see design
>>>> on
>>>>>> it starting.
>>>>>>
>>>>>> The ability for an intermediate server that is likely already
>>>>>> authenticating end users, to send end user identity down to Drill adds
>>>> a
>>>>>> key element into an end to end secure design by enabling Drill and the
>>>>> back
>>>>>> end systems to see the real user and thus perform meaningful
>>>>> authorization.
>>>>>>
>>>>>> Back when I was building many JEE applications I know the DBAs where
>>>> very
>>>>>> frustrated that the application servers blinded them to the identity
>> of
>>>>> the
>>>>>> end user accessing important corporate data. When JEE application
>>>> servers
>>>>>> and databases finally added the ability to impersonate that addressed
>> a
>>>>> lot
>>>>>> of security concerns. Of course this isn't a perfect solution and I'm
>>>>> sure
>>>>>> others will recognize that in some scenarios impersonation isn't the
>>>> best
>>>>>> approach, but having that as an option in Drill is very valuable.
>>>>>>
>>>>>> Keys
>>>>>> _______________________________
>>>>>> Keys Botzum
>>>>>> Senior Principal Technologist
>>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>>>> 443-718-0098
>>>>>> MapR Technologies
>>>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hey y’all,
>>>>>>>
>>>>>>> I plan to work on DRILL-4281 <
>>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>>>> inbound/client impersonation. Please review the design document <
>>>>>>
>>>>>
>>>>
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
>>>>>> ,
>>>>>> which is open for comments. There is also a link to proof-of-concept
>>>>>> (slightly hacky).
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Sudheesh
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Neeraja Rentachintala <nr...@maprtech.com>.
It seems to me that for phase 1, we should only have this as connection
level property and have the list of proxy users as a static bootstrap
option. Drill doesn't have a very granular privilege model other than
admins vs non-admins, so till then exposing this via system options seems
like a risk to me from a security standpoint.
-Neeraja
On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam <sk...@maprtech.com>
wrote:
> “… when creating this connection, as part of the connection properties
> (JDBC, C++ Client), the application passes the end user’s identity (e.g.
> username) …”
>
> I had written the change user as a session option as part of the
> enhancement only, where you’ve pointed out a better way. I addressed your
> comments on the doc.
>
> Thank you,
> Sudheesh
>
> > On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
> >
> > Maybe I misunderstood the design document.
> >
> > I thought this was how the user would be changed: "Provide a way to
> change
> > the user after the connection is made (details) through a session option"
> >
> > Did I miss something?
> >
> >
> >
> >
> >
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
> > nrentachintala@maprtech.com> wrote:
> >
> >> Jacques,
> >> I think the current proposal by Sudheesh is an API level change to pass
> >> this additional end user id during the connection establishment.
> >> Can you elaborate what you mean by random query.
> >>
> >> -Neeraja
> >>
> >> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
> >> wrote:
> >>
> >>> Sudheesh, thanks for putting this together. Reviewing Oracle
> >> documentation,
> >>> they expose this at the API level rather than through a random query. I
> >>> think we should probably model after that rather than invent a new
> >>> mechanism. This also means we can avoid things like query parsing,
> >>> execution roundtrip, query profiles, etc to provide this functionality.
> >>>
> >>> See here:
> >>>
> >>>
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
> >>>
> >>> --
> >>> Jacques Nadeau
> >>> CTO and Co-Founder, Dremio
> >>>
> >>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
> >> wrote:
> >>>
> >>>> This is a great feature to add to Drill and I'm excited to see design
> >> on
> >>>> it starting.
> >>>>
> >>>> The ability for an intermediate server that is likely already
> >>>> authenticating end users, to send end user identity down to Drill adds
> >> a
> >>>> key element into an end to end secure design by enabling Drill and the
> >>> back
> >>>> end systems to see the real user and thus perform meaningful
> >>> authorization.
> >>>>
> >>>> Back when I was building many JEE applications I know the DBAs where
> >> very
> >>>> frustrated that the application servers blinded them to the identity
> of
> >>> the
> >>>> end user accessing important corporate data. When JEE application
> >> servers
> >>>> and databases finally added the ability to impersonate that addressed
> a
> >>> lot
> >>>> of security concerns. Of course this isn't a perfect solution and I'm
> >>> sure
> >>>> others will recognize that in some scenarios impersonation isn't the
> >> best
> >>>> approach, but having that as an option in Drill is very valuable.
> >>>>
> >>>> Keys
> >>>> _______________________________
> >>>> Keys Botzum
> >>>> Senior Principal Technologist
> >>>> kbotzum@maprtech.com <ma...@maprtech.com>
> >>>> 443-718-0098
> >>>> MapR Technologies
> >>>> http://www.mapr.com <http://www.mapr.com/>
> >>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> >>>> wrote:
> >>>>>
> >>>>> Hey y’all,
> >>>>>
> >>>>> I plan to work on DRILL-4281 <
> >>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
> >>>> inbound/client impersonation. Please review the design document <
> >>>>
> >>>
> >>
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
> >>>> ,
> >>>> which is open for comments. There is also a link to proof-of-concept
> >>>> (slightly hacky).
> >>>>>
> >>>>> Thank you,
> >>>>> Sudheesh
> >>>>
> >>>>
> >>>
> >>
>
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Sudheesh Katkam <sk...@maprtech.com>.
Thank you all for the feedback.
+ I am naming this feature User Delegation (since Client Impersonation can be confused with User Impersonation).
+ I updated the design document <https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>.
+ I opened a pull request (#400 <https://github.com/apache/drill/pull/400>).
- Sudheesh
> On Feb 23, 2016, at 12:04 PM, Neeraja Rentachintala <nr...@maprtech.com> wrote:
>
> Norris
> Quick comment on your point below. The username/password passed currently
> on the connection string is for authentication purposes and also used for
> impersonation in case of direct connection from BI tool to Drillbit. That
> continue to exist, but now the driver needs to be extended to pass an
> *'additional'* user name as part of connection and this represents the end
> user identity on behalf of which Drill will execute queries (there is an
> intermediate hop via the BI server which we are trying to support).
> Sudheesh doc has specifics on the proposal.
>
> With regards to interfacing the impersonation feature, it looks like all
> you need is the username, which is already being pass down from the
> application to the client via the driver.
>
> On Tue, Feb 23, 2016 at 11:52 AM, Norris Lee <no...@simba.com> wrote:
>
>> ODBC does not have any standard way to change the user for a connection,
>> so like Sudheesh mentioned, I'm not sure how this would be exposed to the
>> application. I believe some other databases like SQLServer let you change
>> the user via SQL.
>>
>> With regards to interfacing the impersonation feature, it looks like all
>> you need is the username, which is already being pass down from the
>> application to the client via the driver.
>>
>> Norris
>>
>> -----Original Message-----
>> From: Sudheesh Katkam [mailto:skatkam@maprtech.com]
>> Sent: Tuesday, February 23, 2016 8:49 AM
>> To: user@drill.apache.org
>> Cc: dev <de...@drill.apache.org>
>> Subject: Re: [DISCUSS] New Feature: Drill Client Impersonation
>>
>>> Do you have an interface proposal? I didn't see that.
>>
>> Are you referring to the Drill client interface to used by applications?
>>
>>> Also, what do you think about my comment and Keys response about moving
>> pooling to the Driver and then making "connection" lightweight.
>>
>> An API to change the user on a connection can be easily added later (for
>> now, we use a connection property). Since Drill connections are already
>> lightweight, this is not an immediate problem. Unlike OracleConnection <
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA>,
>> JDBC/ ODBC do not have a provision for proxy sessions in their
>> specification, so I am not entirely clear how we would expose “change user
>> on connection” to applications using these API.
>>
>>> Connection level identity setting is only viable if the scalability
>> concerns I raised in the doc and Jacques indirectly raised are addressed.
>>>
>>> Historically DB connections have been so expensive that most
>> applications created pools of connections and reused them across users.
>> That model doesn't work if each connection is tied to a single user. That's
>> why the typical implementation has provided for changing the identity on an
>> existing connection.
>>>
>>> Now, if the Drill connection is a very lightweight object (possibly
>> mapping to a single heavier weight hidden process level object), then tying
>> identity to the connection is fine. I don't know enough about the Drill
>> architecture to comment on that but I think a good rule of thumb would be
>> "is it reasonable to keep 50+ Drill connections open where each has a
>> different user identity?" If the answer is no, then the design needs to
>> consider the scale. I'll also add that much further in the future if/when
>> Drill takes on more operational types of access that 50 connections will
>> rise to a much larger number.
>>
>>
>> Thank you,
>> Sudheesh
>>
>>> On Feb 22, 2016, at 2:27 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>>>
>>> Got it, makes sense.
>>>
>>> Do you have an interface proposal? I didn't see that.
>>>
>>> Also, what do you think about my comment and Keys response about
>>> moving pooling to the Driver and then making "connection" lightweight.
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam
>>> <sk...@maprtech.com>
>>> wrote:
>>>
>>>> “… when creating this connection, as part of the connection
>>>> properties (JDBC, C++ Client), the application passes the end user’s
>> identity (e.g.
>>>> username) …”
>>>>
>>>> I had written the change user as a session option as part of the
>>>> enhancement only, where you’ve pointed out a better way. I addressed
>>>> your comments on the doc.
>>>>
>>>> Thank you,
>>>> Sudheesh
>>>>
>>>>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com>
>> wrote:
>>>>>
>>>>> Maybe I misunderstood the design document.
>>>>>
>>>>> I thought this was how the user would be changed: "Provide a way to
>>>> change
>>>>> the user after the connection is made (details) through a session
>> option"
>>>>>
>>>>> Did I miss something?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jacques Nadeau
>>>>> CTO and Co-Founder, Dremio
>>>>>
>>>>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
>>>>> nrentachintala@maprtech.com> wrote:
>>>>>
>>>>>> Jacques,
>>>>>> I think the current proposal by Sudheesh is an API level change to
>>>>>> pass this additional end user id during the connection establishment.
>>>>>> Can you elaborate what you mean by random query.
>>>>>>
>>>>>> -Neeraja
>>>>>>
>>>>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau
>>>>>> <ja...@dremio.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>>>>>> documentation,
>>>>>>> they expose this at the API level rather than through a random
>>>>>>> query. I think we should probably model after that rather than
>>>>>>> invent a new mechanism. This also means we can avoid things like
>>>>>>> query parsing, execution roundtrip, query profiles, etc to provide
>> this functionality.
>>>>>>>
>>>>>>> See here:
>>>>>>>
>>>>>>>
>>>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJ
>>>> EIA
>>>>>>>
>>>>>>> --
>>>>>>> Jacques Nadeau
>>>>>>> CTO and Co-Founder, Dremio
>>>>>>>
>>>>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum
>>>>>>> <kb...@maprtech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> This is a great feature to add to Drill and I'm excited to see
>>>>>>>> design
>>>>>> on
>>>>>>>> it starting.
>>>>>>>>
>>>>>>>> The ability for an intermediate server that is likely already
>>>>>>>> authenticating end users, to send end user identity down to Drill
>>>>>>>> adds
>>>>>> a
>>>>>>>> key element into an end to end secure design by enabling Drill
>>>>>>>> and the
>>>>>>> back
>>>>>>>> end systems to see the real user and thus perform meaningful
>>>>>>> authorization.
>>>>>>>>
>>>>>>>> Back when I was building many JEE applications I know the DBAs
>>>>>>>> where
>>>>>> very
>>>>>>>> frustrated that the application servers blinded them to the
>>>>>>>> identity
>>>> of
>>>>>>> the
>>>>>>>> end user accessing important corporate data. When JEE application
>>>>>> servers
>>>>>>>> and databases finally added the ability to impersonate that
>>>>>>>> addressed
>>>> a
>>>>>>> lot
>>>>>>>> of security concerns. Of course this isn't a perfect solution and
>>>>>>>> I'm
>>>>>>> sure
>>>>>>>> others will recognize that in some scenarios impersonation isn't
>>>>>>>> the
>>>>>> best
>>>>>>>> approach, but having that as an option in Drill is very valuable.
>>>>>>>>
>>>>>>>> Keys
>>>>>>>> _______________________________
>>>>>>>> Keys Botzum
>>>>>>>> Senior Principal Technologist
>>>>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>>>>>> 443-718-0098
>>>>>>>> MapR Technologies
>>>>>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam
>>>>>>>>> <sk...@maprtech.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hey y’all,
>>>>>>>>>
>>>>>>>>> I plan to work on DRILL-4281 <
>>>>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>>>>>> inbound/client impersonation. Please review the design document <
>>>>>>>>
>>>>>>>
>>>>>>
>>>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb
>>>> 38k-npvwjA
>>>>>>>> ,
>>>>>>>> which is open for comments. There is also a link to
>>>>>>>> proof-of-concept (slightly hacky).
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Sudheesh
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Sudheesh Katkam <sk...@maprtech.com>.
Thank you all for the feedback.
+ I am naming this feature User Delegation (since Client Impersonation can be confused with User Impersonation).
+ I updated the design document <https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>.
+ I opened a pull request (#400 <https://github.com/apache/drill/pull/400>).
- Sudheesh
> On Feb 23, 2016, at 12:04 PM, Neeraja Rentachintala <nr...@maprtech.com> wrote:
>
> Norris
> Quick comment on your point below. The username/password passed currently
> on the connection string is for authentication purposes and also used for
> impersonation in case of direct connection from BI tool to Drillbit. That
> continue to exist, but now the driver needs to be extended to pass an
> *'additional'* user name as part of connection and this represents the end
> user identity on behalf of which Drill will execute queries (there is an
> intermediate hop via the BI server which we are trying to support).
> Sudheesh doc has specifics on the proposal.
>
> With regards to interfacing the impersonation feature, it looks like all
> you need is the username, which is already being pass down from the
> application to the client via the driver.
>
> On Tue, Feb 23, 2016 at 11:52 AM, Norris Lee <no...@simba.com> wrote:
>
>> ODBC does not have any standard way to change the user for a connection,
>> so like Sudheesh mentioned, I'm not sure how this would be exposed to the
>> application. I believe some other databases like SQLServer let you change
>> the user via SQL.
>>
>> With regards to interfacing the impersonation feature, it looks like all
>> you need is the username, which is already being pass down from the
>> application to the client via the driver.
>>
>> Norris
>>
>> -----Original Message-----
>> From: Sudheesh Katkam [mailto:skatkam@maprtech.com]
>> Sent: Tuesday, February 23, 2016 8:49 AM
>> To: user@drill.apache.org
>> Cc: dev <de...@drill.apache.org>
>> Subject: Re: [DISCUSS] New Feature: Drill Client Impersonation
>>
>>> Do you have an interface proposal? I didn't see that.
>>
>> Are you referring to the Drill client interface to used by applications?
>>
>>> Also, what do you think about my comment and Keys response about moving
>> pooling to the Driver and then making "connection" lightweight.
>>
>> An API to change the user on a connection can be easily added later (for
>> now, we use a connection property). Since Drill connections are already
>> lightweight, this is not an immediate problem. Unlike OracleConnection <
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA>,
>> JDBC/ ODBC do not have a provision for proxy sessions in their
>> specification, so I am not entirely clear how we would expose “change user
>> on connection” to applications using these API.
>>
>>> Connection level identity setting is only viable if the scalability
>> concerns I raised in the doc and Jacques indirectly raised are addressed.
>>>
>>> Historically DB connections have been so expensive that most
>> applications created pools of connections and reused them across users.
>> That model doesn't work if each connection is tied to a single user. That's
>> why the typical implementation has provided for changing the identity on an
>> existing connection.
>>>
>>> Now, if the Drill connection is a very lightweight object (possibly
>> mapping to a single heavier weight hidden process level object), then tying
>> identity to the connection is fine. I don't know enough about the Drill
>> architecture to comment on that but I think a good rule of thumb would be
>> "is it reasonable to keep 50+ Drill connections open where each has a
>> different user identity?" If the answer is no, then the design needs to
>> consider the scale. I'll also add that much further in the future if/when
>> Drill takes on more operational types of access that 50 connections will
>> rise to a much larger number.
>>
>>
>> Thank you,
>> Sudheesh
>>
>>> On Feb 22, 2016, at 2:27 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>>>
>>> Got it, makes sense.
>>>
>>> Do you have an interface proposal? I didn't see that.
>>>
>>> Also, what do you think about my comment and Keys response about
>>> moving pooling to the Driver and then making "connection" lightweight.
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam
>>> <sk...@maprtech.com>
>>> wrote:
>>>
>>>> “… when creating this connection, as part of the connection
>>>> properties (JDBC, C++ Client), the application passes the end user’s
>> identity (e.g.
>>>> username) …”
>>>>
>>>> I had written the change user as a session option as part of the
>>>> enhancement only, where you’ve pointed out a better way. I addressed
>>>> your comments on the doc.
>>>>
>>>> Thank you,
>>>> Sudheesh
>>>>
>>>>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com>
>> wrote:
>>>>>
>>>>> Maybe I misunderstood the design document.
>>>>>
>>>>> I thought this was how the user would be changed: "Provide a way to
>>>> change
>>>>> the user after the connection is made (details) through a session
>> option"
>>>>>
>>>>> Did I miss something?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jacques Nadeau
>>>>> CTO and Co-Founder, Dremio
>>>>>
>>>>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
>>>>> nrentachintala@maprtech.com> wrote:
>>>>>
>>>>>> Jacques,
>>>>>> I think the current proposal by Sudheesh is an API level change to
>>>>>> pass this additional end user id during the connection establishment.
>>>>>> Can you elaborate what you mean by random query.
>>>>>>
>>>>>> -Neeraja
>>>>>>
>>>>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau
>>>>>> <ja...@dremio.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>>>>>> documentation,
>>>>>>> they expose this at the API level rather than through a random
>>>>>>> query. I think we should probably model after that rather than
>>>>>>> invent a new mechanism. This also means we can avoid things like
>>>>>>> query parsing, execution roundtrip, query profiles, etc to provide
>> this functionality.
>>>>>>>
>>>>>>> See here:
>>>>>>>
>>>>>>>
>>>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJ
>>>> EIA
>>>>>>>
>>>>>>> --
>>>>>>> Jacques Nadeau
>>>>>>> CTO and Co-Founder, Dremio
>>>>>>>
>>>>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum
>>>>>>> <kb...@maprtech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> This is a great feature to add to Drill and I'm excited to see
>>>>>>>> design
>>>>>> on
>>>>>>>> it starting.
>>>>>>>>
>>>>>>>> The ability for an intermediate server that is likely already
>>>>>>>> authenticating end users, to send end user identity down to Drill
>>>>>>>> adds
>>>>>> a
>>>>>>>> key element into an end to end secure design by enabling Drill
>>>>>>>> and the
>>>>>>> back
>>>>>>>> end systems to see the real user and thus perform meaningful
>>>>>>> authorization.
>>>>>>>>
>>>>>>>> Back when I was building many JEE applications I know the DBAs
>>>>>>>> where
>>>>>> very
>>>>>>>> frustrated that the application servers blinded them to the
>>>>>>>> identity
>>>> of
>>>>>>> the
>>>>>>>> end user accessing important corporate data. When JEE application
>>>>>> servers
>>>>>>>> and databases finally added the ability to impersonate that
>>>>>>>> addressed
>>>> a
>>>>>>> lot
>>>>>>>> of security concerns. Of course this isn't a perfect solution and
>>>>>>>> I'm
>>>>>>> sure
>>>>>>>> others will recognize that in some scenarios impersonation isn't
>>>>>>>> the
>>>>>> best
>>>>>>>> approach, but having that as an option in Drill is very valuable.
>>>>>>>>
>>>>>>>> Keys
>>>>>>>> _______________________________
>>>>>>>> Keys Botzum
>>>>>>>> Senior Principal Technologist
>>>>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>>>>>> 443-718-0098
>>>>>>>> MapR Technologies
>>>>>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam
>>>>>>>>> <sk...@maprtech.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hey y’all,
>>>>>>>>>
>>>>>>>>> I plan to work on DRILL-4281 <
>>>>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>>>>>> inbound/client impersonation. Please review the design document <
>>>>>>>>
>>>>>>>
>>>>>>
>>>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb
>>>> 38k-npvwjA
>>>>>>>> ,
>>>>>>>> which is open for comments. There is also a link to
>>>>>>>> proof-of-concept (slightly hacky).
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Sudheesh
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Neeraja Rentachintala <nr...@maprtech.com>.
Norris
Quick comment on your point below. The username/password passed currently
on the connection string is for authentication purposes and also used for
impersonation in case of direct connection from BI tool to Drillbit. That
continue to exist, but now the driver needs to be extended to pass an
*'additional'* user name as part of connection and this represents the end
user identity on behalf of which Drill will execute queries (there is an
intermediate hop via the BI server which we are trying to support).
Sudheesh doc has specifics on the proposal.
With regards to interfacing the impersonation feature, it looks like all
you need is the username, which is already being pass down from the
application to the client via the driver.
On Tue, Feb 23, 2016 at 11:52 AM, Norris Lee <no...@simba.com> wrote:
> ODBC does not have any standard way to change the user for a connection,
> so like Sudheesh mentioned, I'm not sure how this would be exposed to the
> application. I believe some other databases like SQLServer let you change
> the user via SQL.
>
> With regards to interfacing the impersonation feature, it looks like all
> you need is the username, which is already being pass down from the
> application to the client via the driver.
>
> Norris
>
> -----Original Message-----
> From: Sudheesh Katkam [mailto:skatkam@maprtech.com]
> Sent: Tuesday, February 23, 2016 8:49 AM
> To: user@drill.apache.org
> Cc: dev <de...@drill.apache.org>
> Subject: Re: [DISCUSS] New Feature: Drill Client Impersonation
>
> > Do you have an interface proposal? I didn't see that.
>
> Are you referring to the Drill client interface to used by applications?
>
> > Also, what do you think about my comment and Keys response about moving
> pooling to the Driver and then making "connection" lightweight.
>
> An API to change the user on a connection can be easily added later (for
> now, we use a connection property). Since Drill connections are already
> lightweight, this is not an immediate problem. Unlike OracleConnection <
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA>,
> JDBC/ ODBC do not have a provision for proxy sessions in their
> specification, so I am not entirely clear how we would expose “change user
> on connection” to applications using these API.
>
> > Connection level identity setting is only viable if the scalability
> concerns I raised in the doc and Jacques indirectly raised are addressed.
> >
> > Historically DB connections have been so expensive that most
> applications created pools of connections and reused them across users.
> That model doesn't work if each connection is tied to a single user. That's
> why the typical implementation has provided for changing the identity on an
> existing connection.
> >
> > Now, if the Drill connection is a very lightweight object (possibly
> mapping to a single heavier weight hidden process level object), then tying
> identity to the connection is fine. I don't know enough about the Drill
> architecture to comment on that but I think a good rule of thumb would be
> "is it reasonable to keep 50+ Drill connections open where each has a
> different user identity?" If the answer is no, then the design needs to
> consider the scale. I'll also add that much further in the future if/when
> Drill takes on more operational types of access that 50 connections will
> rise to a much larger number.
>
>
> Thank you,
> Sudheesh
>
> > On Feb 22, 2016, at 2:27 PM, Jacques Nadeau <ja...@dremio.com> wrote:
> >
> > Got it, makes sense.
> >
> > Do you have an interface proposal? I didn't see that.
> >
> > Also, what do you think about my comment and Keys response about
> > moving pooling to the Driver and then making "connection" lightweight.
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam
> > <sk...@maprtech.com>
> > wrote:
> >
> >> “… when creating this connection, as part of the connection
> >> properties (JDBC, C++ Client), the application passes the end user’s
> identity (e.g.
> >> username) …”
> >>
> >> I had written the change user as a session option as part of the
> >> enhancement only, where you’ve pointed out a better way. I addressed
> >> your comments on the doc.
> >>
> >> Thank you,
> >> Sudheesh
> >>
> >>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com>
> wrote:
> >>>
> >>> Maybe I misunderstood the design document.
> >>>
> >>> I thought this was how the user would be changed: "Provide a way to
> >> change
> >>> the user after the connection is made (details) through a session
> option"
> >>>
> >>> Did I miss something?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jacques Nadeau
> >>> CTO and Co-Founder, Dremio
> >>>
> >>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
> >>> nrentachintala@maprtech.com> wrote:
> >>>
> >>>> Jacques,
> >>>> I think the current proposal by Sudheesh is an API level change to
> >>>> pass this additional end user id during the connection establishment.
> >>>> Can you elaborate what you mean by random query.
> >>>>
> >>>> -Neeraja
> >>>>
> >>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau
> >>>> <ja...@dremio.com>
> >>>> wrote:
> >>>>
> >>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
> >>>> documentation,
> >>>>> they expose this at the API level rather than through a random
> >>>>> query. I think we should probably model after that rather than
> >>>>> invent a new mechanism. This also means we can avoid things like
> >>>>> query parsing, execution roundtrip, query profiles, etc to provide
> this functionality.
> >>>>>
> >>>>> See here:
> >>>>>
> >>>>>
> >> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJ
> >> EIA
> >>>>>
> >>>>> --
> >>>>> Jacques Nadeau
> >>>>> CTO and Co-Founder, Dremio
> >>>>>
> >>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum
> >>>>> <kb...@maprtech.com>
> >>>> wrote:
> >>>>>
> >>>>>> This is a great feature to add to Drill and I'm excited to see
> >>>>>> design
> >>>> on
> >>>>>> it starting.
> >>>>>>
> >>>>>> The ability for an intermediate server that is likely already
> >>>>>> authenticating end users, to send end user identity down to Drill
> >>>>>> adds
> >>>> a
> >>>>>> key element into an end to end secure design by enabling Drill
> >>>>>> and the
> >>>>> back
> >>>>>> end systems to see the real user and thus perform meaningful
> >>>>> authorization.
> >>>>>>
> >>>>>> Back when I was building many JEE applications I know the DBAs
> >>>>>> where
> >>>> very
> >>>>>> frustrated that the application servers blinded them to the
> >>>>>> identity
> >> of
> >>>>> the
> >>>>>> end user accessing important corporate data. When JEE application
> >>>> servers
> >>>>>> and databases finally added the ability to impersonate that
> >>>>>> addressed
> >> a
> >>>>> lot
> >>>>>> of security concerns. Of course this isn't a perfect solution and
> >>>>>> I'm
> >>>>> sure
> >>>>>> others will recognize that in some scenarios impersonation isn't
> >>>>>> the
> >>>> best
> >>>>>> approach, but having that as an option in Drill is very valuable.
> >>>>>>
> >>>>>> Keys
> >>>>>> _______________________________
> >>>>>> Keys Botzum
> >>>>>> Senior Principal Technologist
> >>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
> >>>>>> 443-718-0098
> >>>>>> MapR Technologies
> >>>>>> http://www.mapr.com <http://www.mapr.com/>
> >>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam
> >>>>>>> <sk...@maprtech.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hey y’all,
> >>>>>>>
> >>>>>>> I plan to work on DRILL-4281 <
> >>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
> >>>>>> inbound/client impersonation. Please review the design document <
> >>>>>>
> >>>>>
> >>>>
> >> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb
> >> 38k-npvwjA
> >>>>>> ,
> >>>>>> which is open for comments. There is also a link to
> >>>>>> proof-of-concept (slightly hacky).
> >>>>>>>
> >>>>>>> Thank you,
> >>>>>>> Sudheesh
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Neeraja Rentachintala <nr...@maprtech.com>.
Norris
Quick comment on your point below. The username/password passed currently
on the connection string is for authentication purposes and also used for
impersonation in case of direct connection from BI tool to Drillbit. That
continue to exist, but now the driver needs to be extended to pass an
*'additional'* user name as part of connection and this represents the end
user identity on behalf of which Drill will execute queries (there is an
intermediate hop via the BI server which we are trying to support).
Sudheesh doc has specifics on the proposal.
With regards to interfacing the impersonation feature, it looks like all
you need is the username, which is already being pass down from the
application to the client via the driver.
On Tue, Feb 23, 2016 at 11:52 AM, Norris Lee <no...@simba.com> wrote:
> ODBC does not have any standard way to change the user for a connection,
> so like Sudheesh mentioned, I'm not sure how this would be exposed to the
> application. I believe some other databases like SQLServer let you change
> the user via SQL.
>
> With regards to interfacing the impersonation feature, it looks like all
> you need is the username, which is already being pass down from the
> application to the client via the driver.
>
> Norris
>
> -----Original Message-----
> From: Sudheesh Katkam [mailto:skatkam@maprtech.com]
> Sent: Tuesday, February 23, 2016 8:49 AM
> To: user@drill.apache.org
> Cc: dev <de...@drill.apache.org>
> Subject: Re: [DISCUSS] New Feature: Drill Client Impersonation
>
> > Do you have an interface proposal? I didn't see that.
>
> Are you referring to the Drill client interface to used by applications?
>
> > Also, what do you think about my comment and Keys response about moving
> pooling to the Driver and then making "connection" lightweight.
>
> An API to change the user on a connection can be easily added later (for
> now, we use a connection property). Since Drill connections are already
> lightweight, this is not an immediate problem. Unlike OracleConnection <
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA>,
> JDBC/ ODBC do not have a provision for proxy sessions in their
> specification, so I am not entirely clear how we would expose “change user
> on connection” to applications using these API.
>
> > Connection level identity setting is only viable if the scalability
> concerns I raised in the doc and Jacques indirectly raised are addressed.
> >
> > Historically DB connections have been so expensive that most
> applications created pools of connections and reused them across users.
> That model doesn't work if each connection is tied to a single user. That's
> why the typical implementation has provided for changing the identity on an
> existing connection.
> >
> > Now, if the Drill connection is a very lightweight object (possibly
> mapping to a single heavier weight hidden process level object), then tying
> identity to the connection is fine. I don't know enough about the Drill
> architecture to comment on that but I think a good rule of thumb would be
> "is it reasonable to keep 50+ Drill connections open where each has a
> different user identity?" If the answer is no, then the design needs to
> consider the scale. I'll also add that much further in the future if/when
> Drill takes on more operational types of access that 50 connections will
> rise to a much larger number.
>
>
> Thank you,
> Sudheesh
>
> > On Feb 22, 2016, at 2:27 PM, Jacques Nadeau <ja...@dremio.com> wrote:
> >
> > Got it, makes sense.
> >
> > Do you have an interface proposal? I didn't see that.
> >
> > Also, what do you think about my comment and Keys response about
> > moving pooling to the Driver and then making "connection" lightweight.
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam
> > <sk...@maprtech.com>
> > wrote:
> >
> >> “… when creating this connection, as part of the connection
> >> properties (JDBC, C++ Client), the application passes the end user’s
> identity (e.g.
> >> username) …”
> >>
> >> I had written the change user as a session option as part of the
> >> enhancement only, where you’ve pointed out a better way. I addressed
> >> your comments on the doc.
> >>
> >> Thank you,
> >> Sudheesh
> >>
> >>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com>
> wrote:
> >>>
> >>> Maybe I misunderstood the design document.
> >>>
> >>> I thought this was how the user would be changed: "Provide a way to
> >> change
> >>> the user after the connection is made (details) through a session
> option"
> >>>
> >>> Did I miss something?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jacques Nadeau
> >>> CTO and Co-Founder, Dremio
> >>>
> >>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
> >>> nrentachintala@maprtech.com> wrote:
> >>>
> >>>> Jacques,
> >>>> I think the current proposal by Sudheesh is an API level change to
> >>>> pass this additional end user id during the connection establishment.
> >>>> Can you elaborate what you mean by random query.
> >>>>
> >>>> -Neeraja
> >>>>
> >>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau
> >>>> <ja...@dremio.com>
> >>>> wrote:
> >>>>
> >>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
> >>>> documentation,
> >>>>> they expose this at the API level rather than through a random
> >>>>> query. I think we should probably model after that rather than
> >>>>> invent a new mechanism. This also means we can avoid things like
> >>>>> query parsing, execution roundtrip, query profiles, etc to provide
> this functionality.
> >>>>>
> >>>>> See here:
> >>>>>
> >>>>>
> >> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJ
> >> EIA
> >>>>>
> >>>>> --
> >>>>> Jacques Nadeau
> >>>>> CTO and Co-Founder, Dremio
> >>>>>
> >>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum
> >>>>> <kb...@maprtech.com>
> >>>> wrote:
> >>>>>
> >>>>>> This is a great feature to add to Drill and I'm excited to see
> >>>>>> design
> >>>> on
> >>>>>> it starting.
> >>>>>>
> >>>>>> The ability for an intermediate server that is likely already
> >>>>>> authenticating end users, to send end user identity down to Drill
> >>>>>> adds
> >>>> a
> >>>>>> key element into an end to end secure design by enabling Drill
> >>>>>> and the
> >>>>> back
> >>>>>> end systems to see the real user and thus perform meaningful
> >>>>> authorization.
> >>>>>>
> >>>>>> Back when I was building many JEE applications I know the DBAs
> >>>>>> where
> >>>> very
> >>>>>> frustrated that the application servers blinded them to the
> >>>>>> identity
> >> of
> >>>>> the
> >>>>>> end user accessing important corporate data. When JEE application
> >>>> servers
> >>>>>> and databases finally added the ability to impersonate that
> >>>>>> addressed
> >> a
> >>>>> lot
> >>>>>> of security concerns. Of course this isn't a perfect solution and
> >>>>>> I'm
> >>>>> sure
> >>>>>> others will recognize that in some scenarios impersonation isn't
> >>>>>> the
> >>>> best
> >>>>>> approach, but having that as an option in Drill is very valuable.
> >>>>>>
> >>>>>> Keys
> >>>>>> _______________________________
> >>>>>> Keys Botzum
> >>>>>> Senior Principal Technologist
> >>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
> >>>>>> 443-718-0098
> >>>>>> MapR Technologies
> >>>>>> http://www.mapr.com <http://www.mapr.com/>
> >>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam
> >>>>>>> <sk...@maprtech.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hey y’all,
> >>>>>>>
> >>>>>>> I plan to work on DRILL-4281 <
> >>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
> >>>>>> inbound/client impersonation. Please review the design document <
> >>>>>>
> >>>>>
> >>>>
> >> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb
> >> 38k-npvwjA
> >>>>>> ,
> >>>>>> which is open for comments. There is also a link to
> >>>>>> proof-of-concept (slightly hacky).
> >>>>>>>
> >>>>>>> Thank you,
> >>>>>>> Sudheesh
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>
> >>
>
>
RE: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Norris Lee <no...@simba.com>.
ODBC does not have any standard way to change the user for a connection, so like Sudheesh mentioned, I'm not sure how this would be exposed to the application. I believe some other databases like SQLServer let you change the user via SQL.
With regards to interfacing the impersonation feature, it looks like all you need is the username, which is already being pass down from the application to the client via the driver.
Norris
-----Original Message-----
From: Sudheesh Katkam [mailto:skatkam@maprtech.com]
Sent: Tuesday, February 23, 2016 8:49 AM
To: user@drill.apache.org
Cc: dev <de...@drill.apache.org>
Subject: Re: [DISCUSS] New Feature: Drill Client Impersonation
> Do you have an interface proposal? I didn't see that.
Are you referring to the Drill client interface to used by applications?
> Also, what do you think about my comment and Keys response about moving pooling to the Driver and then making "connection" lightweight.
An API to change the user on a connection can be easily added later (for now, we use a connection property). Since Drill connections are already lightweight, this is not an immediate problem. Unlike OracleConnection <https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA>, JDBC/ ODBC do not have a provision for proxy sessions in their specification, so I am not entirely clear how we would expose “change user on connection” to applications using these API.
> Connection level identity setting is only viable if the scalability concerns I raised in the doc and Jacques indirectly raised are addressed.
>
> Historically DB connections have been so expensive that most applications created pools of connections and reused them across users. That model doesn't work if each connection is tied to a single user. That's why the typical implementation has provided for changing the identity on an existing connection.
>
> Now, if the Drill connection is a very lightweight object (possibly mapping to a single heavier weight hidden process level object), then tying identity to the connection is fine. I don't know enough about the Drill architecture to comment on that but I think a good rule of thumb would be "is it reasonable to keep 50+ Drill connections open where each has a different user identity?" If the answer is no, then the design needs to consider the scale. I'll also add that much further in the future if/when Drill takes on more operational types of access that 50 connections will rise to a much larger number.
Thank you,
Sudheesh
> On Feb 22, 2016, at 2:27 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>
> Got it, makes sense.
>
> Do you have an interface proposal? I didn't see that.
>
> Also, what do you think about my comment and Keys response about
> moving pooling to the Driver and then making "connection" lightweight.
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam
> <sk...@maprtech.com>
> wrote:
>
>> “… when creating this connection, as part of the connection
>> properties (JDBC, C++ Client), the application passes the end user’s identity (e.g.
>> username) …”
>>
>> I had written the change user as a session option as part of the
>> enhancement only, where you’ve pointed out a better way. I addressed
>> your comments on the doc.
>>
>> Thank you,
>> Sudheesh
>>
>>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
>>>
>>> Maybe I misunderstood the design document.
>>>
>>> I thought this was how the user would be changed: "Provide a way to
>> change
>>> the user after the connection is made (details) through a session option"
>>>
>>> Did I miss something?
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
>>> nrentachintala@maprtech.com> wrote:
>>>
>>>> Jacques,
>>>> I think the current proposal by Sudheesh is an API level change to
>>>> pass this additional end user id during the connection establishment.
>>>> Can you elaborate what you mean by random query.
>>>>
>>>> -Neeraja
>>>>
>>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau
>>>> <ja...@dremio.com>
>>>> wrote:
>>>>
>>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>>>> documentation,
>>>>> they expose this at the API level rather than through a random
>>>>> query. I think we should probably model after that rather than
>>>>> invent a new mechanism. This also means we can avoid things like
>>>>> query parsing, execution roundtrip, query profiles, etc to provide this functionality.
>>>>>
>>>>> See here:
>>>>>
>>>>>
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJ
>> EIA
>>>>>
>>>>> --
>>>>> Jacques Nadeau
>>>>> CTO and Co-Founder, Dremio
>>>>>
>>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum
>>>>> <kb...@maprtech.com>
>>>> wrote:
>>>>>
>>>>>> This is a great feature to add to Drill and I'm excited to see
>>>>>> design
>>>> on
>>>>>> it starting.
>>>>>>
>>>>>> The ability for an intermediate server that is likely already
>>>>>> authenticating end users, to send end user identity down to Drill
>>>>>> adds
>>>> a
>>>>>> key element into an end to end secure design by enabling Drill
>>>>>> and the
>>>>> back
>>>>>> end systems to see the real user and thus perform meaningful
>>>>> authorization.
>>>>>>
>>>>>> Back when I was building many JEE applications I know the DBAs
>>>>>> where
>>>> very
>>>>>> frustrated that the application servers blinded them to the
>>>>>> identity
>> of
>>>>> the
>>>>>> end user accessing important corporate data. When JEE application
>>>> servers
>>>>>> and databases finally added the ability to impersonate that
>>>>>> addressed
>> a
>>>>> lot
>>>>>> of security concerns. Of course this isn't a perfect solution and
>>>>>> I'm
>>>>> sure
>>>>>> others will recognize that in some scenarios impersonation isn't
>>>>>> the
>>>> best
>>>>>> approach, but having that as an option in Drill is very valuable.
>>>>>>
>>>>>> Keys
>>>>>> _______________________________
>>>>>> Keys Botzum
>>>>>> Senior Principal Technologist
>>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>>>> 443-718-0098
>>>>>> MapR Technologies
>>>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam
>>>>>>> <sk...@maprtech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hey y’all,
>>>>>>>
>>>>>>> I plan to work on DRILL-4281 <
>>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>>>> inbound/client impersonation. Please review the design document <
>>>>>>
>>>>>
>>>>
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb
>> 38k-npvwjA
>>>>>> ,
>>>>>> which is open for comments. There is also a link to
>>>>>> proof-of-concept (slightly hacky).
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Sudheesh
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
RE: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Norris Lee <no...@simba.com>.
ODBC does not have any standard way to change the user for a connection, so like Sudheesh mentioned, I'm not sure how this would be exposed to the application. I believe some other databases like SQLServer let you change the user via SQL.
With regards to interfacing the impersonation feature, it looks like all you need is the username, which is already being pass down from the application to the client via the driver.
Norris
-----Original Message-----
From: Sudheesh Katkam [mailto:skatkam@maprtech.com]
Sent: Tuesday, February 23, 2016 8:49 AM
To: user@drill.apache.org
Cc: dev <de...@drill.apache.org>
Subject: Re: [DISCUSS] New Feature: Drill Client Impersonation
> Do you have an interface proposal? I didn't see that.
Are you referring to the Drill client interface to used by applications?
> Also, what do you think about my comment and Keys response about moving pooling to the Driver and then making "connection" lightweight.
An API to change the user on a connection can be easily added later (for now, we use a connection property). Since Drill connections are already lightweight, this is not an immediate problem. Unlike OracleConnection <https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA>, JDBC/ ODBC do not have a provision for proxy sessions in their specification, so I am not entirely clear how we would expose “change user on connection” to applications using these API.
> Connection level identity setting is only viable if the scalability concerns I raised in the doc and Jacques indirectly raised are addressed.
>
> Historically DB connections have been so expensive that most applications created pools of connections and reused them across users. That model doesn't work if each connection is tied to a single user. That's why the typical implementation has provided for changing the identity on an existing connection.
>
> Now, if the Drill connection is a very lightweight object (possibly mapping to a single heavier weight hidden process level object), then tying identity to the connection is fine. I don't know enough about the Drill architecture to comment on that but I think a good rule of thumb would be "is it reasonable to keep 50+ Drill connections open where each has a different user identity?" If the answer is no, then the design needs to consider the scale. I'll also add that much further in the future if/when Drill takes on more operational types of access that 50 connections will rise to a much larger number.
Thank you,
Sudheesh
> On Feb 22, 2016, at 2:27 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>
> Got it, makes sense.
>
> Do you have an interface proposal? I didn't see that.
>
> Also, what do you think about my comment and Keys response about
> moving pooling to the Driver and then making "connection" lightweight.
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam
> <sk...@maprtech.com>
> wrote:
>
>> “… when creating this connection, as part of the connection
>> properties (JDBC, C++ Client), the application passes the end user’s identity (e.g.
>> username) …”
>>
>> I had written the change user as a session option as part of the
>> enhancement only, where you’ve pointed out a better way. I addressed
>> your comments on the doc.
>>
>> Thank you,
>> Sudheesh
>>
>>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
>>>
>>> Maybe I misunderstood the design document.
>>>
>>> I thought this was how the user would be changed: "Provide a way to
>> change
>>> the user after the connection is made (details) through a session option"
>>>
>>> Did I miss something?
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
>>> nrentachintala@maprtech.com> wrote:
>>>
>>>> Jacques,
>>>> I think the current proposal by Sudheesh is an API level change to
>>>> pass this additional end user id during the connection establishment.
>>>> Can you elaborate what you mean by random query.
>>>>
>>>> -Neeraja
>>>>
>>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau
>>>> <ja...@dremio.com>
>>>> wrote:
>>>>
>>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>>>> documentation,
>>>>> they expose this at the API level rather than through a random
>>>>> query. I think we should probably model after that rather than
>>>>> invent a new mechanism. This also means we can avoid things like
>>>>> query parsing, execution roundtrip, query profiles, etc to provide this functionality.
>>>>>
>>>>> See here:
>>>>>
>>>>>
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJ
>> EIA
>>>>>
>>>>> --
>>>>> Jacques Nadeau
>>>>> CTO and Co-Founder, Dremio
>>>>>
>>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum
>>>>> <kb...@maprtech.com>
>>>> wrote:
>>>>>
>>>>>> This is a great feature to add to Drill and I'm excited to see
>>>>>> design
>>>> on
>>>>>> it starting.
>>>>>>
>>>>>> The ability for an intermediate server that is likely already
>>>>>> authenticating end users, to send end user identity down to Drill
>>>>>> adds
>>>> a
>>>>>> key element into an end to end secure design by enabling Drill
>>>>>> and the
>>>>> back
>>>>>> end systems to see the real user and thus perform meaningful
>>>>> authorization.
>>>>>>
>>>>>> Back when I was building many JEE applications I know the DBAs
>>>>>> where
>>>> very
>>>>>> frustrated that the application servers blinded them to the
>>>>>> identity
>> of
>>>>> the
>>>>>> end user accessing important corporate data. When JEE application
>>>> servers
>>>>>> and databases finally added the ability to impersonate that
>>>>>> addressed
>> a
>>>>> lot
>>>>>> of security concerns. Of course this isn't a perfect solution and
>>>>>> I'm
>>>>> sure
>>>>>> others will recognize that in some scenarios impersonation isn't
>>>>>> the
>>>> best
>>>>>> approach, but having that as an option in Drill is very valuable.
>>>>>>
>>>>>> Keys
>>>>>> _______________________________
>>>>>> Keys Botzum
>>>>>> Senior Principal Technologist
>>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>>>> 443-718-0098
>>>>>> MapR Technologies
>>>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam
>>>>>>> <sk...@maprtech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hey y’all,
>>>>>>>
>>>>>>> I plan to work on DRILL-4281 <
>>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>>>> inbound/client impersonation. Please review the design document <
>>>>>>
>>>>>
>>>>
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb
>> 38k-npvwjA
>>>>>> ,
>>>>>> which is open for comments. There is also a link to
>>>>>> proof-of-concept (slightly hacky).
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Sudheesh
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Sudheesh Katkam <sk...@maprtech.com>.
> Do you have an interface proposal? I didn't see that.
Are you referring to the Drill client interface to used by applications?
> Also, what do you think about my comment and Keys response about moving pooling to the Driver and then making "connection" lightweight.
An API to change the user on a connection can be easily added later (for now, we use a connection property). Since Drill connections are already lightweight, this is not an immediate problem. Unlike OracleConnection <https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA>, JDBC/ ODBC do not have a provision for proxy sessions in their specification, so I am not entirely clear how we would expose “change user on connection” to applications using these API.
> Connection level identity setting is only viable if the scalability concerns I raised in the doc and Jacques indirectly raised are addressed.
>
> Historically DB connections have been so expensive that most applications created pools of connections and reused them across users. That model doesn't work if each connection is tied to a single user. That's why the typical implementation has provided for changing the identity on an existing connection.
>
> Now, if the Drill connection is a very lightweight object (possibly mapping to a single heavier weight hidden process level object), then tying identity to the connection is fine. I don't know enough about the Drill architecture to comment on that but I think a good rule of thumb would be "is it reasonable to keep 50+ Drill connections open where each has a different user identity?" If the answer is no, then the design needs to consider the scale. I'll also add that much further in the future if/when Drill takes on more operational types of access that 50 connections will rise to a much larger number.
Thank you,
Sudheesh
> On Feb 22, 2016, at 2:27 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>
> Got it, makes sense.
>
> Do you have an interface proposal? I didn't see that.
>
> Also, what do you think about my comment and Keys response about moving
> pooling to the Driver and then making "connection" lightweight.
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam <sk...@maprtech.com>
> wrote:
>
>> “… when creating this connection, as part of the connection properties
>> (JDBC, C++ Client), the application passes the end user’s identity (e.g.
>> username) …”
>>
>> I had written the change user as a session option as part of the
>> enhancement only, where you’ve pointed out a better way. I addressed your
>> comments on the doc.
>>
>> Thank you,
>> Sudheesh
>>
>>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
>>>
>>> Maybe I misunderstood the design document.
>>>
>>> I thought this was how the user would be changed: "Provide a way to
>> change
>>> the user after the connection is made (details) through a session option"
>>>
>>> Did I miss something?
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
>>> nrentachintala@maprtech.com> wrote:
>>>
>>>> Jacques,
>>>> I think the current proposal by Sudheesh is an API level change to pass
>>>> this additional end user id during the connection establishment.
>>>> Can you elaborate what you mean by random query.
>>>>
>>>> -Neeraja
>>>>
>>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
>>>> wrote:
>>>>
>>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>>>> documentation,
>>>>> they expose this at the API level rather than through a random query. I
>>>>> think we should probably model after that rather than invent a new
>>>>> mechanism. This also means we can avoid things like query parsing,
>>>>> execution roundtrip, query profiles, etc to provide this functionality.
>>>>>
>>>>> See here:
>>>>>
>>>>>
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>>>>>
>>>>> --
>>>>> Jacques Nadeau
>>>>> CTO and Co-Founder, Dremio
>>>>>
>>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
>>>> wrote:
>>>>>
>>>>>> This is a great feature to add to Drill and I'm excited to see design
>>>> on
>>>>>> it starting.
>>>>>>
>>>>>> The ability for an intermediate server that is likely already
>>>>>> authenticating end users, to send end user identity down to Drill adds
>>>> a
>>>>>> key element into an end to end secure design by enabling Drill and the
>>>>> back
>>>>>> end systems to see the real user and thus perform meaningful
>>>>> authorization.
>>>>>>
>>>>>> Back when I was building many JEE applications I know the DBAs where
>>>> very
>>>>>> frustrated that the application servers blinded them to the identity
>> of
>>>>> the
>>>>>> end user accessing important corporate data. When JEE application
>>>> servers
>>>>>> and databases finally added the ability to impersonate that addressed
>> a
>>>>> lot
>>>>>> of security concerns. Of course this isn't a perfect solution and I'm
>>>>> sure
>>>>>> others will recognize that in some scenarios impersonation isn't the
>>>> best
>>>>>> approach, but having that as an option in Drill is very valuable.
>>>>>>
>>>>>> Keys
>>>>>> _______________________________
>>>>>> Keys Botzum
>>>>>> Senior Principal Technologist
>>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>>>> 443-718-0098
>>>>>> MapR Technologies
>>>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hey y’all,
>>>>>>>
>>>>>>> I plan to work on DRILL-4281 <
>>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>>>> inbound/client impersonation. Please review the design document <
>>>>>>
>>>>>
>>>>
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
>>>>>> ,
>>>>>> which is open for comments. There is also a link to proof-of-concept
>>>>>> (slightly hacky).
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Sudheesh
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Sudheesh Katkam <sk...@maprtech.com>.
> Do you have an interface proposal? I didn't see that.
Are you referring to the Drill client interface to used by applications?
> Also, what do you think about my comment and Keys response about moving pooling to the Driver and then making "connection" lightweight.
An API to change the user on a connection can be easily added later (for now, we use a connection property). Since Drill connections are already lightweight, this is not an immediate problem. Unlike OracleConnection <https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA>, JDBC/ ODBC do not have a provision for proxy sessions in their specification, so I am not entirely clear how we would expose “change user on connection” to applications using these API.
> Connection level identity setting is only viable if the scalability concerns I raised in the doc and Jacques indirectly raised are addressed.
>
> Historically DB connections have been so expensive that most applications created pools of connections and reused them across users. That model doesn't work if each connection is tied to a single user. That's why the typical implementation has provided for changing the identity on an existing connection.
>
> Now, if the Drill connection is a very lightweight object (possibly mapping to a single heavier weight hidden process level object), then tying identity to the connection is fine. I don't know enough about the Drill architecture to comment on that but I think a good rule of thumb would be "is it reasonable to keep 50+ Drill connections open where each has a different user identity?" If the answer is no, then the design needs to consider the scale. I'll also add that much further in the future if/when Drill takes on more operational types of access that 50 connections will rise to a much larger number.
Thank you,
Sudheesh
> On Feb 22, 2016, at 2:27 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>
> Got it, makes sense.
>
> Do you have an interface proposal? I didn't see that.
>
> Also, what do you think about my comment and Keys response about moving
> pooling to the Driver and then making "connection" lightweight.
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam <sk...@maprtech.com>
> wrote:
>
>> “… when creating this connection, as part of the connection properties
>> (JDBC, C++ Client), the application passes the end user’s identity (e.g.
>> username) …”
>>
>> I had written the change user as a session option as part of the
>> enhancement only, where you’ve pointed out a better way. I addressed your
>> comments on the doc.
>>
>> Thank you,
>> Sudheesh
>>
>>> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
>>>
>>> Maybe I misunderstood the design document.
>>>
>>> I thought this was how the user would be changed: "Provide a way to
>> change
>>> the user after the connection is made (details) through a session option"
>>>
>>> Did I miss something?
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
>>> nrentachintala@maprtech.com> wrote:
>>>
>>>> Jacques,
>>>> I think the current proposal by Sudheesh is an API level change to pass
>>>> this additional end user id during the connection establishment.
>>>> Can you elaborate what you mean by random query.
>>>>
>>>> -Neeraja
>>>>
>>>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
>>>> wrote:
>>>>
>>>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>>>> documentation,
>>>>> they expose this at the API level rather than through a random query. I
>>>>> think we should probably model after that rather than invent a new
>>>>> mechanism. This also means we can avoid things like query parsing,
>>>>> execution roundtrip, query profiles, etc to provide this functionality.
>>>>>
>>>>> See here:
>>>>>
>>>>>
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>>>>>
>>>>> --
>>>>> Jacques Nadeau
>>>>> CTO and Co-Founder, Dremio
>>>>>
>>>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
>>>> wrote:
>>>>>
>>>>>> This is a great feature to add to Drill and I'm excited to see design
>>>> on
>>>>>> it starting.
>>>>>>
>>>>>> The ability for an intermediate server that is likely already
>>>>>> authenticating end users, to send end user identity down to Drill adds
>>>> a
>>>>>> key element into an end to end secure design by enabling Drill and the
>>>>> back
>>>>>> end systems to see the real user and thus perform meaningful
>>>>> authorization.
>>>>>>
>>>>>> Back when I was building many JEE applications I know the DBAs where
>>>> very
>>>>>> frustrated that the application servers blinded them to the identity
>> of
>>>>> the
>>>>>> end user accessing important corporate data. When JEE application
>>>> servers
>>>>>> and databases finally added the ability to impersonate that addressed
>> a
>>>>> lot
>>>>>> of security concerns. Of course this isn't a perfect solution and I'm
>>>>> sure
>>>>>> others will recognize that in some scenarios impersonation isn't the
>>>> best
>>>>>> approach, but having that as an option in Drill is very valuable.
>>>>>>
>>>>>> Keys
>>>>>> _______________________________
>>>>>> Keys Botzum
>>>>>> Senior Principal Technologist
>>>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>>>> 443-718-0098
>>>>>> MapR Technologies
>>>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hey y’all,
>>>>>>>
>>>>>>> I plan to work on DRILL-4281 <
>>>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>>>> inbound/client impersonation. Please review the design document <
>>>>>>
>>>>>
>>>>
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
>>>>>> ,
>>>>>> which is open for comments. There is also a link to proof-of-concept
>>>>>> (slightly hacky).
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Sudheesh
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Jacques Nadeau <ja...@dremio.com>.
Got it, makes sense.
Do you have an interface proposal? I didn't see that.
Also, what do you think about my comment and Keys response about moving
pooling to the Driver and then making "connection" lightweight.
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam <sk...@maprtech.com>
wrote:
> “… when creating this connection, as part of the connection properties
> (JDBC, C++ Client), the application passes the end user’s identity (e.g.
> username) …”
>
> I had written the change user as a session option as part of the
> enhancement only, where you’ve pointed out a better way. I addressed your
> comments on the doc.
>
> Thank you,
> Sudheesh
>
> > On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
> >
> > Maybe I misunderstood the design document.
> >
> > I thought this was how the user would be changed: "Provide a way to
> change
> > the user after the connection is made (details) through a session option"
> >
> > Did I miss something?
> >
> >
> >
> >
> >
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
> > nrentachintala@maprtech.com> wrote:
> >
> >> Jacques,
> >> I think the current proposal by Sudheesh is an API level change to pass
> >> this additional end user id during the connection establishment.
> >> Can you elaborate what you mean by random query.
> >>
> >> -Neeraja
> >>
> >> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
> >> wrote:
> >>
> >>> Sudheesh, thanks for putting this together. Reviewing Oracle
> >> documentation,
> >>> they expose this at the API level rather than through a random query. I
> >>> think we should probably model after that rather than invent a new
> >>> mechanism. This also means we can avoid things like query parsing,
> >>> execution roundtrip, query profiles, etc to provide this functionality.
> >>>
> >>> See here:
> >>>
> >>>
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
> >>>
> >>> --
> >>> Jacques Nadeau
> >>> CTO and Co-Founder, Dremio
> >>>
> >>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
> >> wrote:
> >>>
> >>>> This is a great feature to add to Drill and I'm excited to see design
> >> on
> >>>> it starting.
> >>>>
> >>>> The ability for an intermediate server that is likely already
> >>>> authenticating end users, to send end user identity down to Drill adds
> >> a
> >>>> key element into an end to end secure design by enabling Drill and the
> >>> back
> >>>> end systems to see the real user and thus perform meaningful
> >>> authorization.
> >>>>
> >>>> Back when I was building many JEE applications I know the DBAs where
> >> very
> >>>> frustrated that the application servers blinded them to the identity
> of
> >>> the
> >>>> end user accessing important corporate data. When JEE application
> >> servers
> >>>> and databases finally added the ability to impersonate that addressed
> a
> >>> lot
> >>>> of security concerns. Of course this isn't a perfect solution and I'm
> >>> sure
> >>>> others will recognize that in some scenarios impersonation isn't the
> >> best
> >>>> approach, but having that as an option in Drill is very valuable.
> >>>>
> >>>> Keys
> >>>> _______________________________
> >>>> Keys Botzum
> >>>> Senior Principal Technologist
> >>>> kbotzum@maprtech.com <ma...@maprtech.com>
> >>>> 443-718-0098
> >>>> MapR Technologies
> >>>> http://www.mapr.com <http://www.mapr.com/>
> >>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> >>>> wrote:
> >>>>>
> >>>>> Hey y’all,
> >>>>>
> >>>>> I plan to work on DRILL-4281 <
> >>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
> >>>> inbound/client impersonation. Please review the design document <
> >>>>
> >>>
> >>
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
> >>>> ,
> >>>> which is open for comments. There is also a link to proof-of-concept
> >>>> (slightly hacky).
> >>>>>
> >>>>> Thank you,
> >>>>> Sudheesh
> >>>>
> >>>>
> >>>
> >>
>
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Jacques Nadeau <ja...@dremio.com>.
Got it, makes sense.
Do you have an interface proposal? I didn't see that.
Also, what do you think about my comment and Keys response about moving
pooling to the Driver and then making "connection" lightweight.
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam <sk...@maprtech.com>
wrote:
> “… when creating this connection, as part of the connection properties
> (JDBC, C++ Client), the application passes the end user’s identity (e.g.
> username) …”
>
> I had written the change user as a session option as part of the
> enhancement only, where you’ve pointed out a better way. I addressed your
> comments on the doc.
>
> Thank you,
> Sudheesh
>
> > On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
> >
> > Maybe I misunderstood the design document.
> >
> > I thought this was how the user would be changed: "Provide a way to
> change
> > the user after the connection is made (details) through a session option"
> >
> > Did I miss something?
> >
> >
> >
> >
> >
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
> > nrentachintala@maprtech.com> wrote:
> >
> >> Jacques,
> >> I think the current proposal by Sudheesh is an API level change to pass
> >> this additional end user id during the connection establishment.
> >> Can you elaborate what you mean by random query.
> >>
> >> -Neeraja
> >>
> >> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
> >> wrote:
> >>
> >>> Sudheesh, thanks for putting this together. Reviewing Oracle
> >> documentation,
> >>> they expose this at the API level rather than through a random query. I
> >>> think we should probably model after that rather than invent a new
> >>> mechanism. This also means we can avoid things like query parsing,
> >>> execution roundtrip, query profiles, etc to provide this functionality.
> >>>
> >>> See here:
> >>>
> >>>
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
> >>>
> >>> --
> >>> Jacques Nadeau
> >>> CTO and Co-Founder, Dremio
> >>>
> >>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
> >> wrote:
> >>>
> >>>> This is a great feature to add to Drill and I'm excited to see design
> >> on
> >>>> it starting.
> >>>>
> >>>> The ability for an intermediate server that is likely already
> >>>> authenticating end users, to send end user identity down to Drill adds
> >> a
> >>>> key element into an end to end secure design by enabling Drill and the
> >>> back
> >>>> end systems to see the real user and thus perform meaningful
> >>> authorization.
> >>>>
> >>>> Back when I was building many JEE applications I know the DBAs where
> >> very
> >>>> frustrated that the application servers blinded them to the identity
> of
> >>> the
> >>>> end user accessing important corporate data. When JEE application
> >> servers
> >>>> and databases finally added the ability to impersonate that addressed
> a
> >>> lot
> >>>> of security concerns. Of course this isn't a perfect solution and I'm
> >>> sure
> >>>> others will recognize that in some scenarios impersonation isn't the
> >> best
> >>>> approach, but having that as an option in Drill is very valuable.
> >>>>
> >>>> Keys
> >>>> _______________________________
> >>>> Keys Botzum
> >>>> Senior Principal Technologist
> >>>> kbotzum@maprtech.com <ma...@maprtech.com>
> >>>> 443-718-0098
> >>>> MapR Technologies
> >>>> http://www.mapr.com <http://www.mapr.com/>
> >>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> >>>> wrote:
> >>>>>
> >>>>> Hey y’all,
> >>>>>
> >>>>> I plan to work on DRILL-4281 <
> >>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
> >>>> inbound/client impersonation. Please review the design document <
> >>>>
> >>>
> >>
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
> >>>> ,
> >>>> which is open for comments. There is also a link to proof-of-concept
> >>>> (slightly hacky).
> >>>>>
> >>>>> Thank you,
> >>>>> Sudheesh
> >>>>
> >>>>
> >>>
> >>
>
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Neeraja Rentachintala <nr...@maprtech.com>.
It seems to me that for phase 1, we should only have this as connection
level property and have the list of proxy users as a static bootstrap
option. Drill doesn't have a very granular privilege model other than
admins vs non-admins, so till then exposing this via system options seems
like a risk to me from a security standpoint.
-Neeraja
On Mon, Feb 22, 2016 at 9:59 AM, Sudheesh Katkam <sk...@maprtech.com>
wrote:
> “… when creating this connection, as part of the connection properties
> (JDBC, C++ Client), the application passes the end user’s identity (e.g.
> username) …”
>
> I had written the change user as a session option as part of the
> enhancement only, where you’ve pointed out a better way. I addressed your
> comments on the doc.
>
> Thank you,
> Sudheesh
>
> > On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
> >
> > Maybe I misunderstood the design document.
> >
> > I thought this was how the user would be changed: "Provide a way to
> change
> > the user after the connection is made (details) through a session option"
> >
> > Did I miss something?
> >
> >
> >
> >
> >
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
> > nrentachintala@maprtech.com> wrote:
> >
> >> Jacques,
> >> I think the current proposal by Sudheesh is an API level change to pass
> >> this additional end user id during the connection establishment.
> >> Can you elaborate what you mean by random query.
> >>
> >> -Neeraja
> >>
> >> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
> >> wrote:
> >>
> >>> Sudheesh, thanks for putting this together. Reviewing Oracle
> >> documentation,
> >>> they expose this at the API level rather than through a random query. I
> >>> think we should probably model after that rather than invent a new
> >>> mechanism. This also means we can avoid things like query parsing,
> >>> execution roundtrip, query profiles, etc to provide this functionality.
> >>>
> >>> See here:
> >>>
> >>>
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
> >>>
> >>> --
> >>> Jacques Nadeau
> >>> CTO and Co-Founder, Dremio
> >>>
> >>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
> >> wrote:
> >>>
> >>>> This is a great feature to add to Drill and I'm excited to see design
> >> on
> >>>> it starting.
> >>>>
> >>>> The ability for an intermediate server that is likely already
> >>>> authenticating end users, to send end user identity down to Drill adds
> >> a
> >>>> key element into an end to end secure design by enabling Drill and the
> >>> back
> >>>> end systems to see the real user and thus perform meaningful
> >>> authorization.
> >>>>
> >>>> Back when I was building many JEE applications I know the DBAs where
> >> very
> >>>> frustrated that the application servers blinded them to the identity
> of
> >>> the
> >>>> end user accessing important corporate data. When JEE application
> >> servers
> >>>> and databases finally added the ability to impersonate that addressed
> a
> >>> lot
> >>>> of security concerns. Of course this isn't a perfect solution and I'm
> >>> sure
> >>>> others will recognize that in some scenarios impersonation isn't the
> >> best
> >>>> approach, but having that as an option in Drill is very valuable.
> >>>>
> >>>> Keys
> >>>> _______________________________
> >>>> Keys Botzum
> >>>> Senior Principal Technologist
> >>>> kbotzum@maprtech.com <ma...@maprtech.com>
> >>>> 443-718-0098
> >>>> MapR Technologies
> >>>> http://www.mapr.com <http://www.mapr.com/>
> >>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> >>>> wrote:
> >>>>>
> >>>>> Hey y’all,
> >>>>>
> >>>>> I plan to work on DRILL-4281 <
> >>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
> >>>> inbound/client impersonation. Please review the design document <
> >>>>
> >>>
> >>
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
> >>>> ,
> >>>> which is open for comments. There is also a link to proof-of-concept
> >>>> (slightly hacky).
> >>>>>
> >>>>> Thank you,
> >>>>> Sudheesh
> >>>>
> >>>>
> >>>
> >>
>
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Sudheesh Katkam <sk...@maprtech.com>.
“… when creating this connection, as part of the connection properties (JDBC, C++ Client), the application passes the end user’s identity (e.g. username) …”
I had written the change user as a session option as part of the enhancement only, where you’ve pointed out a better way. I addressed your comments on the doc.
Thank you,
Sudheesh
> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
>
> Maybe I misunderstood the design document.
>
> I thought this was how the user would be changed: "Provide a way to change
> the user after the connection is made (details) through a session option"
>
> Did I miss something?
>
>
>
>
>
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
> nrentachintala@maprtech.com> wrote:
>
>> Jacques,
>> I think the current proposal by Sudheesh is an API level change to pass
>> this additional end user id during the connection establishment.
>> Can you elaborate what you mean by random query.
>>
>> -Neeraja
>>
>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
>> wrote:
>>
>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>> documentation,
>>> they expose this at the API level rather than through a random query. I
>>> think we should probably model after that rather than invent a new
>>> mechanism. This also means we can avoid things like query parsing,
>>> execution roundtrip, query profiles, etc to provide this functionality.
>>>
>>> See here:
>>>
>>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
>> wrote:
>>>
>>>> This is a great feature to add to Drill and I'm excited to see design
>> on
>>>> it starting.
>>>>
>>>> The ability for an intermediate server that is likely already
>>>> authenticating end users, to send end user identity down to Drill adds
>> a
>>>> key element into an end to end secure design by enabling Drill and the
>>> back
>>>> end systems to see the real user and thus perform meaningful
>>> authorization.
>>>>
>>>> Back when I was building many JEE applications I know the DBAs where
>> very
>>>> frustrated that the application servers blinded them to the identity of
>>> the
>>>> end user accessing important corporate data. When JEE application
>> servers
>>>> and databases finally added the ability to impersonate that addressed a
>>> lot
>>>> of security concerns. Of course this isn't a perfect solution and I'm
>>> sure
>>>> others will recognize that in some scenarios impersonation isn't the
>> best
>>>> approach, but having that as an option in Drill is very valuable.
>>>>
>>>> Keys
>>>> _______________________________
>>>> Keys Botzum
>>>> Senior Principal Technologist
>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>> 443-718-0098
>>>> MapR Technologies
>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>>>> wrote:
>>>>>
>>>>> Hey y’all,
>>>>>
>>>>> I plan to work on DRILL-4281 <
>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>> inbound/client impersonation. Please review the design document <
>>>>
>>>
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
>>>> ,
>>>> which is open for comments. There is also a link to proof-of-concept
>>>> (slightly hacky).
>>>>>
>>>>> Thank you,
>>>>> Sudheesh
>>>>
>>>>
>>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Sudheesh Katkam <sk...@maprtech.com>.
“… when creating this connection, as part of the connection properties (JDBC, C++ Client), the application passes the end user’s identity (e.g. username) …”
I had written the change user as a session option as part of the enhancement only, where you’ve pointed out a better way. I addressed your comments on the doc.
Thank you,
Sudheesh
> On Feb 22, 2016, at 9:49 AM, Jacques Nadeau <ja...@dremio.com> wrote:
>
> Maybe I misunderstood the design document.
>
> I thought this was how the user would be changed: "Provide a way to change
> the user after the connection is made (details) through a session option"
>
> Did I miss something?
>
>
>
>
>
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
> nrentachintala@maprtech.com> wrote:
>
>> Jacques,
>> I think the current proposal by Sudheesh is an API level change to pass
>> this additional end user id during the connection establishment.
>> Can you elaborate what you mean by random query.
>>
>> -Neeraja
>>
>> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
>> wrote:
>>
>>> Sudheesh, thanks for putting this together. Reviewing Oracle
>> documentation,
>>> they expose this at the API level rather than through a random query. I
>>> think we should probably model after that rather than invent a new
>>> mechanism. This also means we can avoid things like query parsing,
>>> execution roundtrip, query profiles, etc to provide this functionality.
>>>
>>> See here:
>>>
>>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>>>
>>> --
>>> Jacques Nadeau
>>> CTO and Co-Founder, Dremio
>>>
>>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
>> wrote:
>>>
>>>> This is a great feature to add to Drill and I'm excited to see design
>> on
>>>> it starting.
>>>>
>>>> The ability for an intermediate server that is likely already
>>>> authenticating end users, to send end user identity down to Drill adds
>> a
>>>> key element into an end to end secure design by enabling Drill and the
>>> back
>>>> end systems to see the real user and thus perform meaningful
>>> authorization.
>>>>
>>>> Back when I was building many JEE applications I know the DBAs where
>> very
>>>> frustrated that the application servers blinded them to the identity of
>>> the
>>>> end user accessing important corporate data. When JEE application
>> servers
>>>> and databases finally added the ability to impersonate that addressed a
>>> lot
>>>> of security concerns. Of course this isn't a perfect solution and I'm
>>> sure
>>>> others will recognize that in some scenarios impersonation isn't the
>> best
>>>> approach, but having that as an option in Drill is very valuable.
>>>>
>>>> Keys
>>>> _______________________________
>>>> Keys Botzum
>>>> Senior Principal Technologist
>>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>>> 443-718-0098
>>>> MapR Technologies
>>>> http://www.mapr.com <http://www.mapr.com/>
>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>>>> wrote:
>>>>>
>>>>> Hey y’all,
>>>>>
>>>>> I plan to work on DRILL-4281 <
>>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>>> inbound/client impersonation. Please review the design document <
>>>>
>>>
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
>>>> ,
>>>> which is open for comments. There is also a link to proof-of-concept
>>>> (slightly hacky).
>>>>>
>>>>> Thank you,
>>>>> Sudheesh
>>>>
>>>>
>>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Jacques Nadeau <ja...@dremio.com>.
Maybe I misunderstood the design document.
I thought this was how the user would be changed: "Provide a way to change
the user after the connection is made (details) through a session option"
Did I miss something?
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
nrentachintala@maprtech.com> wrote:
> Jacques,
> I think the current proposal by Sudheesh is an API level change to pass
> this additional end user id during the connection establishment.
> Can you elaborate what you mean by random query.
>
> -Neeraja
>
> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
> wrote:
>
> > Sudheesh, thanks for putting this together. Reviewing Oracle
> documentation,
> > they expose this at the API level rather than through a random query. I
> > think we should probably model after that rather than invent a new
> > mechanism. This also means we can avoid things like query parsing,
> > execution roundtrip, query profiles, etc to provide this functionality.
> >
> > See here:
> >
> > https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
> wrote:
> >
> > > This is a great feature to add to Drill and I'm excited to see design
> on
> > > it starting.
> > >
> > > The ability for an intermediate server that is likely already
> > > authenticating end users, to send end user identity down to Drill adds
> a
> > > key element into an end to end secure design by enabling Drill and the
> > back
> > > end systems to see the real user and thus perform meaningful
> > authorization.
> > >
> > > Back when I was building many JEE applications I know the DBAs where
> very
> > > frustrated that the application servers blinded them to the identity of
> > the
> > > end user accessing important corporate data. When JEE application
> servers
> > > and databases finally added the ability to impersonate that addressed a
> > lot
> > > of security concerns. Of course this isn't a perfect solution and I'm
> > sure
> > > others will recognize that in some scenarios impersonation isn't the
> best
> > > approach, but having that as an option in Drill is very valuable.
> > >
> > > Keys
> > > _______________________________
> > > Keys Botzum
> > > Senior Principal Technologist
> > > kbotzum@maprtech.com <ma...@maprtech.com>
> > > 443-718-0098
> > > MapR Technologies
> > > http://www.mapr.com <http://www.mapr.com/>
> > > > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> > > wrote:
> > > >
> > > > Hey y’all,
> > > >
> > > > I plan to work on DRILL-4281 <
> > > https://issues.apache.org/jira/browse/DRILL-4281>: support for
> > > inbound/client impersonation. Please review the design document <
> > >
> >
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
> > >,
> > > which is open for comments. There is also a link to proof-of-concept
> > > (slightly hacky).
> > > >
> > > > Thank you,
> > > > Sudheesh
> > >
> > >
> >
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Jacques Nadeau <ja...@dremio.com>.
Maybe I misunderstood the design document.
I thought this was how the user would be changed: "Provide a way to change
the user after the connection is made (details) through a session option"
Did I miss something?
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Mon, Feb 22, 2016 at 9:06 AM, Neeraja Rentachintala <
nrentachintala@maprtech.com> wrote:
> Jacques,
> I think the current proposal by Sudheesh is an API level change to pass
> this additional end user id during the connection establishment.
> Can you elaborate what you mean by random query.
>
> -Neeraja
>
> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com>
> wrote:
>
> > Sudheesh, thanks for putting this together. Reviewing Oracle
> documentation,
> > they expose this at the API level rather than through a random query. I
> > think we should probably model after that rather than invent a new
> > mechanism. This also means we can avoid things like query parsing,
> > execution roundtrip, query profiles, etc to provide this functionality.
> >
> > See here:
> >
> > https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com>
> wrote:
> >
> > > This is a great feature to add to Drill and I'm excited to see design
> on
> > > it starting.
> > >
> > > The ability for an intermediate server that is likely already
> > > authenticating end users, to send end user identity down to Drill adds
> a
> > > key element into an end to end secure design by enabling Drill and the
> > back
> > > end systems to see the real user and thus perform meaningful
> > authorization.
> > >
> > > Back when I was building many JEE applications I know the DBAs where
> very
> > > frustrated that the application servers blinded them to the identity of
> > the
> > > end user accessing important corporate data. When JEE application
> servers
> > > and databases finally added the ability to impersonate that addressed a
> > lot
> > > of security concerns. Of course this isn't a perfect solution and I'm
> > sure
> > > others will recognize that in some scenarios impersonation isn't the
> best
> > > approach, but having that as an option in Drill is very valuable.
> > >
> > > Keys
> > > _______________________________
> > > Keys Botzum
> > > Senior Principal Technologist
> > > kbotzum@maprtech.com <ma...@maprtech.com>
> > > 443-718-0098
> > > MapR Technologies
> > > http://www.mapr.com <http://www.mapr.com/>
> > > > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> > > wrote:
> > > >
> > > > Hey y’all,
> > > >
> > > > I plan to work on DRILL-4281 <
> > > https://issues.apache.org/jira/browse/DRILL-4281>: support for
> > > inbound/client impersonation. Please review the design document <
> > >
> >
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
> > >,
> > > which is open for comments. There is also a link to proof-of-concept
> > > (slightly hacky).
> > > >
> > > > Thank you,
> > > > Sudheesh
> > >
> > >
> >
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Neeraja Rentachintala <nr...@maprtech.com>.
Jacques,
I think the current proposal by Sudheesh is an API level change to pass
this additional end user id during the connection establishment.
Can you elaborate what you mean by random query.
-Neeraja
On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com> wrote:
> Sudheesh, thanks for putting this together. Reviewing Oracle documentation,
> they expose this at the API level rather than through a random query. I
> think we should probably model after that rather than invent a new
> mechanism. This also means we can avoid things like query parsing,
> execution roundtrip, query profiles, etc to provide this functionality.
>
> See here:
>
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com> wrote:
>
> > This is a great feature to add to Drill and I'm excited to see design on
> > it starting.
> >
> > The ability for an intermediate server that is likely already
> > authenticating end users, to send end user identity down to Drill adds a
> > key element into an end to end secure design by enabling Drill and the
> back
> > end systems to see the real user and thus perform meaningful
> authorization.
> >
> > Back when I was building many JEE applications I know the DBAs where very
> > frustrated that the application servers blinded them to the identity of
> the
> > end user accessing important corporate data. When JEE application servers
> > and databases finally added the ability to impersonate that addressed a
> lot
> > of security concerns. Of course this isn't a perfect solution and I'm
> sure
> > others will recognize that in some scenarios impersonation isn't the best
> > approach, but having that as an option in Drill is very valuable.
> >
> > Keys
> > _______________________________
> > Keys Botzum
> > Senior Principal Technologist
> > kbotzum@maprtech.com <ma...@maprtech.com>
> > 443-718-0098
> > MapR Technologies
> > http://www.mapr.com <http://www.mapr.com/>
> > > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> > wrote:
> > >
> > > Hey y’all,
> > >
> > > I plan to work on DRILL-4281 <
> > https://issues.apache.org/jira/browse/DRILL-4281>: support for
> > inbound/client impersonation. Please review the design document <
> >
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
> >,
> > which is open for comments. There is also a link to proof-of-concept
> > (slightly hacky).
> > >
> > > Thank you,
> > > Sudheesh
> >
> >
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Keys Botzum <kb...@maprtech.com>.
A good suggestion. Pooling is going to important for performance.
Keys
_______________________________
Keys Botzum
Senior Principal Technologist
kbotzum@maprtech.com <ma...@maprtech.com>
443-718-0098
MapR Technologies
http://www.mapr.com <http://www.mapr.com/>
> On Feb 21, 2016, at 8:11 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>
> One other question, have you considered pooling at the Driver level? This
> could work transparently with no API changes. Basically "connections" would
> simply be logical connections over the same tunnel.
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>
>> Sudheesh, thanks for putting this together. Reviewing Oracle
>> documentation, they expose this at the API level rather than through a
>> random query. I think we should probably model after that rather than
>> invent a new mechanism. This also means we can avoid things like query
>> parsing, execution roundtrip, query profiles, etc to provide this
>> functionality.
>>
>> See here:
>>
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>>
>> --
>> Jacques Nadeau
>> CTO and Co-Founder, Dremio
>>
>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com> wrote:
>>
>>> This is a great feature to add to Drill and I'm excited to see design on
>>> it starting.
>>>
>>> The ability for an intermediate server that is likely already
>>> authenticating end users, to send end user identity down to Drill adds a
>>> key element into an end to end secure design by enabling Drill and the back
>>> end systems to see the real user and thus perform meaningful authorization.
>>>
>>> Back when I was building many JEE applications I know the DBAs where very
>>> frustrated that the application servers blinded them to the identity of the
>>> end user accessing important corporate data. When JEE application servers
>>> and databases finally added the ability to impersonate that addressed a lot
>>> of security concerns. Of course this isn't a perfect solution and I'm sure
>>> others will recognize that in some scenarios impersonation isn't the best
>>> approach, but having that as an option in Drill is very valuable.
>>>
>>> Keys
>>> _______________________________
>>> Keys Botzum
>>> Senior Principal Technologist
>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>> 443-718-0098
>>> MapR Technologies
>>> http://www.mapr.com <http://www.mapr.com/>
>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>>> wrote:
>>>>
>>>> Hey y’all,
>>>>
>>>> I plan to work on DRILL-4281 <
>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>> inbound/client impersonation. Please review the design document <
>>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>,
>>> which is open for comments. There is also a link to proof-of-concept
>>> (slightly hacky).
>>>>
>>>> Thank you,
>>>> Sudheesh
>>>
>>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Keys Botzum <kb...@maprtech.com>.
A good suggestion. Pooling is going to important for performance.
Keys
_______________________________
Keys Botzum
Senior Principal Technologist
kbotzum@maprtech.com <ma...@maprtech.com>
443-718-0098
MapR Technologies
http://www.mapr.com <http://www.mapr.com/>
> On Feb 21, 2016, at 8:11 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>
> One other question, have you considered pooling at the Driver level? This
> could work transparently with no API changes. Basically "connections" would
> simply be logical connections over the same tunnel.
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>
>> Sudheesh, thanks for putting this together. Reviewing Oracle
>> documentation, they expose this at the API level rather than through a
>> random query. I think we should probably model after that rather than
>> invent a new mechanism. This also means we can avoid things like query
>> parsing, execution roundtrip, query profiles, etc to provide this
>> functionality.
>>
>> See here:
>>
>> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>>
>> --
>> Jacques Nadeau
>> CTO and Co-Founder, Dremio
>>
>> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com> wrote:
>>
>>> This is a great feature to add to Drill and I'm excited to see design on
>>> it starting.
>>>
>>> The ability for an intermediate server that is likely already
>>> authenticating end users, to send end user identity down to Drill adds a
>>> key element into an end to end secure design by enabling Drill and the back
>>> end systems to see the real user and thus perform meaningful authorization.
>>>
>>> Back when I was building many JEE applications I know the DBAs where very
>>> frustrated that the application servers blinded them to the identity of the
>>> end user accessing important corporate data. When JEE application servers
>>> and databases finally added the ability to impersonate that addressed a lot
>>> of security concerns. Of course this isn't a perfect solution and I'm sure
>>> others will recognize that in some scenarios impersonation isn't the best
>>> approach, but having that as an option in Drill is very valuable.
>>>
>>> Keys
>>> _______________________________
>>> Keys Botzum
>>> Senior Principal Technologist
>>> kbotzum@maprtech.com <ma...@maprtech.com>
>>> 443-718-0098
>>> MapR Technologies
>>> http://www.mapr.com <http://www.mapr.com/>
>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>>> wrote:
>>>>
>>>> Hey y’all,
>>>>
>>>> I plan to work on DRILL-4281 <
>>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>>> inbound/client impersonation. Please review the design document <
>>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>,
>>> which is open for comments. There is also a link to proof-of-concept
>>> (slightly hacky).
>>>>
>>>> Thank you,
>>>> Sudheesh
>>>
>>>
>>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Jacques Nadeau <ja...@dremio.com>.
One other question, have you considered pooling at the Driver level? This
could work transparently with no API changes. Basically "connections" would
simply be logical connections over the same tunnel.
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com> wrote:
> Sudheesh, thanks for putting this together. Reviewing Oracle
> documentation, they expose this at the API level rather than through a
> random query. I think we should probably model after that rather than
> invent a new mechanism. This also means we can avoid things like query
> parsing, execution roundtrip, query profiles, etc to provide this
> functionality.
>
> See here:
>
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com> wrote:
>
>> This is a great feature to add to Drill and I'm excited to see design on
>> it starting.
>>
>> The ability for an intermediate server that is likely already
>> authenticating end users, to send end user identity down to Drill adds a
>> key element into an end to end secure design by enabling Drill and the back
>> end systems to see the real user and thus perform meaningful authorization.
>>
>> Back when I was building many JEE applications I know the DBAs where very
>> frustrated that the application servers blinded them to the identity of the
>> end user accessing important corporate data. When JEE application servers
>> and databases finally added the ability to impersonate that addressed a lot
>> of security concerns. Of course this isn't a perfect solution and I'm sure
>> others will recognize that in some scenarios impersonation isn't the best
>> approach, but having that as an option in Drill is very valuable.
>>
>> Keys
>> _______________________________
>> Keys Botzum
>> Senior Principal Technologist
>> kbotzum@maprtech.com <ma...@maprtech.com>
>> 443-718-0098
>> MapR Technologies
>> http://www.mapr.com <http://www.mapr.com/>
>> > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>> wrote:
>> >
>> > Hey y’all,
>> >
>> > I plan to work on DRILL-4281 <
>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>> inbound/client impersonation. Please review the design document <
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>,
>> which is open for comments. There is also a link to proof-of-concept
>> (slightly hacky).
>> >
>> > Thank you,
>> > Sudheesh
>>
>>
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Jacques Nadeau <ja...@dremio.com>.
One other question, have you considered pooling at the Driver level? This
could work transparently with no API changes. Basically "connections" would
simply be logical connections over the same tunnel.
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com> wrote:
> Sudheesh, thanks for putting this together. Reviewing Oracle
> documentation, they expose this at the API level rather than through a
> random query. I think we should probably model after that rather than
> invent a new mechanism. This also means we can avoid things like query
> parsing, execution roundtrip, query profiles, etc to provide this
> functionality.
>
> See here:
>
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com> wrote:
>
>> This is a great feature to add to Drill and I'm excited to see design on
>> it starting.
>>
>> The ability for an intermediate server that is likely already
>> authenticating end users, to send end user identity down to Drill adds a
>> key element into an end to end secure design by enabling Drill and the back
>> end systems to see the real user and thus perform meaningful authorization.
>>
>> Back when I was building many JEE applications I know the DBAs where very
>> frustrated that the application servers blinded them to the identity of the
>> end user accessing important corporate data. When JEE application servers
>> and databases finally added the ability to impersonate that addressed a lot
>> of security concerns. Of course this isn't a perfect solution and I'm sure
>> others will recognize that in some scenarios impersonation isn't the best
>> approach, but having that as an option in Drill is very valuable.
>>
>> Keys
>> _______________________________
>> Keys Botzum
>> Senior Principal Technologist
>> kbotzum@maprtech.com <ma...@maprtech.com>
>> 443-718-0098
>> MapR Technologies
>> http://www.mapr.com <http://www.mapr.com/>
>> > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
>> wrote:
>> >
>> > Hey y’all,
>> >
>> > I plan to work on DRILL-4281 <
>> https://issues.apache.org/jira/browse/DRILL-4281>: support for
>> inbound/client impersonation. Please review the design document <
>> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>,
>> which is open for comments. There is also a link to proof-of-concept
>> (slightly hacky).
>> >
>> > Thank you,
>> > Sudheesh
>>
>>
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Neeraja Rentachintala <nr...@maprtech.com>.
Jacques,
I think the current proposal by Sudheesh is an API level change to pass
this additional end user id during the connection establishment.
Can you elaborate what you mean by random query.
-Neeraja
On Sun, Feb 21, 2016 at 5:07 PM, Jacques Nadeau <ja...@dremio.com> wrote:
> Sudheesh, thanks for putting this together. Reviewing Oracle documentation,
> they expose this at the API level rather than through a random query. I
> think we should probably model after that rather than invent a new
> mechanism. This also means we can avoid things like query parsing,
> execution roundtrip, query profiles, etc to provide this functionality.
>
> See here:
>
> https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com> wrote:
>
> > This is a great feature to add to Drill and I'm excited to see design on
> > it starting.
> >
> > The ability for an intermediate server that is likely already
> > authenticating end users, to send end user identity down to Drill adds a
> > key element into an end to end secure design by enabling Drill and the
> back
> > end systems to see the real user and thus perform meaningful
> authorization.
> >
> > Back when I was building many JEE applications I know the DBAs where very
> > frustrated that the application servers blinded them to the identity of
> the
> > end user accessing important corporate data. When JEE application servers
> > and databases finally added the ability to impersonate that addressed a
> lot
> > of security concerns. Of course this isn't a perfect solution and I'm
> sure
> > others will recognize that in some scenarios impersonation isn't the best
> > approach, but having that as an option in Drill is very valuable.
> >
> > Keys
> > _______________________________
> > Keys Botzum
> > Senior Principal Technologist
> > kbotzum@maprtech.com <ma...@maprtech.com>
> > 443-718-0098
> > MapR Technologies
> > http://www.mapr.com <http://www.mapr.com/>
> > > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> > wrote:
> > >
> > > Hey y’all,
> > >
> > > I plan to work on DRILL-4281 <
> > https://issues.apache.org/jira/browse/DRILL-4281>: support for
> > inbound/client impersonation. Please review the design document <
> >
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA
> >,
> > which is open for comments. There is also a link to proof-of-concept
> > (slightly hacky).
> > >
> > > Thank you,
> > > Sudheesh
> >
> >
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Jacques Nadeau <ja...@dremio.com>.
Sudheesh, thanks for putting this together. Reviewing Oracle documentation,
they expose this at the API level rather than through a random query. I
think we should probably model after that rather than invent a new
mechanism. This also means we can avoid things like query parsing,
execution roundtrip, query profiles, etc to provide this functionality.
See here:
https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com> wrote:
> This is a great feature to add to Drill and I'm excited to see design on
> it starting.
>
> The ability for an intermediate server that is likely already
> authenticating end users, to send end user identity down to Drill adds a
> key element into an end to end secure design by enabling Drill and the back
> end systems to see the real user and thus perform meaningful authorization.
>
> Back when I was building many JEE applications I know the DBAs where very
> frustrated that the application servers blinded them to the identity of the
> end user accessing important corporate data. When JEE application servers
> and databases finally added the ability to impersonate that addressed a lot
> of security concerns. Of course this isn't a perfect solution and I'm sure
> others will recognize that in some scenarios impersonation isn't the best
> approach, but having that as an option in Drill is very valuable.
>
> Keys
> _______________________________
> Keys Botzum
> Senior Principal Technologist
> kbotzum@maprtech.com <ma...@maprtech.com>
> 443-718-0098
> MapR Technologies
> http://www.mapr.com <http://www.mapr.com/>
> > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> wrote:
> >
> > Hey y’all,
> >
> > I plan to work on DRILL-4281 <
> https://issues.apache.org/jira/browse/DRILL-4281>: support for
> inbound/client impersonation. Please review the design document <
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>,
> which is open for comments. There is also a link to proof-of-concept
> (slightly hacky).
> >
> > Thank you,
> > Sudheesh
>
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Jacques Nadeau <ja...@dremio.com>.
Sudheesh, thanks for putting this together. Reviewing Oracle documentation,
they expose this at the API level rather than through a random query. I
think we should probably model after that rather than invent a new
mechanism. This also means we can avoid things like query parsing,
execution roundtrip, query profiles, etc to provide this functionality.
See here:
https://docs.oracle.com/cd/B28359_01/java.111/b31224/proxya.htm#BABEJEIA
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Fri, Feb 19, 2016 at 2:18 PM, Keys Botzum <kb...@maprtech.com> wrote:
> This is a great feature to add to Drill and I'm excited to see design on
> it starting.
>
> The ability for an intermediate server that is likely already
> authenticating end users, to send end user identity down to Drill adds a
> key element into an end to end secure design by enabling Drill and the back
> end systems to see the real user and thus perform meaningful authorization.
>
> Back when I was building many JEE applications I know the DBAs where very
> frustrated that the application servers blinded them to the identity of the
> end user accessing important corporate data. When JEE application servers
> and databases finally added the ability to impersonate that addressed a lot
> of security concerns. Of course this isn't a perfect solution and I'm sure
> others will recognize that in some scenarios impersonation isn't the best
> approach, but having that as an option in Drill is very valuable.
>
> Keys
> _______________________________
> Keys Botzum
> Senior Principal Technologist
> kbotzum@maprtech.com <ma...@maprtech.com>
> 443-718-0098
> MapR Technologies
> http://www.mapr.com <http://www.mapr.com/>
> > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com>
> wrote:
> >
> > Hey y’all,
> >
> > I plan to work on DRILL-4281 <
> https://issues.apache.org/jira/browse/DRILL-4281>: support for
> inbound/client impersonation. Please review the design document <
> https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>,
> which is open for comments. There is also a link to proof-of-concept
> (slightly hacky).
> >
> > Thank you,
> > Sudheesh
>
>
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Keys Botzum <kb...@maprtech.com>.
This is a great feature to add to Drill and I'm excited to see design on it starting.
The ability for an intermediate server that is likely already authenticating end users, to send end user identity down to Drill adds a key element into an end to end secure design by enabling Drill and the back end systems to see the real user and thus perform meaningful authorization.
Back when I was building many JEE applications I know the DBAs where very frustrated that the application servers blinded them to the identity of the end user accessing important corporate data. When JEE application servers and databases finally added the ability to impersonate that addressed a lot of security concerns. Of course this isn't a perfect solution and I'm sure others will recognize that in some scenarios impersonation isn't the best approach, but having that as an option in Drill is very valuable.
Keys
_______________________________
Keys Botzum
Senior Principal Technologist
kbotzum@maprtech.com <ma...@maprtech.com>
443-718-0098
MapR Technologies
http://www.mapr.com <http://www.mapr.com/>
> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com> wrote:
>
> Hey y’all,
>
> I plan to work on DRILL-4281 <https://issues.apache.org/jira/browse/DRILL-4281>: support for inbound/client impersonation. Please review the design document <https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>, which is open for comments. There is also a link to proof-of-concept (slightly hacky).
>
> Thank you,
> Sudheesh
Re: [DISCUSS] New Feature: Drill Client Impersonation
Posted by Keys Botzum <kb...@maprtech.com>.
This is a great feature to add to Drill and I'm excited to see design on it starting.
The ability for an intermediate server that is likely already authenticating end users, to send end user identity down to Drill adds a key element into an end to end secure design by enabling Drill and the back end systems to see the real user and thus perform meaningful authorization.
Back when I was building many JEE applications I know the DBAs where very frustrated that the application servers blinded them to the identity of the end user accessing important corporate data. When JEE application servers and databases finally added the ability to impersonate that addressed a lot of security concerns. Of course this isn't a perfect solution and I'm sure others will recognize that in some scenarios impersonation isn't the best approach, but having that as an option in Drill is very valuable.
Keys
_______________________________
Keys Botzum
Senior Principal Technologist
kbotzum@maprtech.com <ma...@maprtech.com>
443-718-0098
MapR Technologies
http://www.mapr.com <http://www.mapr.com/>
> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam <sk...@maprtech.com> wrote:
>
> Hey y’all,
>
> I plan to work on DRILL-4281 <https://issues.apache.org/jira/browse/DRILL-4281>: support for inbound/client impersonation. Please review the design document <https://docs.google.com/document/d/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA>, which is open for comments. There is also a link to proof-of-concept (slightly hacky).
>
> Thank you,
> Sudheesh