Re: [DISCUSS] New Feature: Drill Client Impersonation

[Sudheesh Katkam]

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 
>  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  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:skat...@maprtech.com]
>> Sent: Tuesday, February 23, 2016 8:49 AM
>> To: user@drill.apache.org
>> Cc: dev 
>> 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  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
>>> 
>>> wrote:
>&

Re: [DISCUSS] New Feature: Drill Client Impersonation

[Neeraja Rentachintala]

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  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:skat...@maprtech.com]
> Sent: Tuesday, February 23, 2016 8:49 AM
> To: user@drill.apache.org
> Cc: dev 
> 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  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
> > 
> > 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 
> wrote:
> >>>
> >>> Maybe I misunderstood the design document.
> >>>
> >>> I thought this was how the user would be changed: "Provide a way to
> >> change
&g

RE: [DISCUSS] New Feature: Drill Client Impersonation

[Norris Lee]

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:skat...@maprtech.com] 
Sent: Tuesday, February 23, 2016 8:49 AM
To: user@drill.apache.org
Cc: dev 
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  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 
> 
> 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  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 < 
>>> nrentachint...@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 
>>>> 
>>>> 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 shou

Re: [DISCUSS] New Feature: Drill Client Impersonation

[Sudheesh Katkam]

> 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 
, 
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  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 
> 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  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 <
>>> nrentachint...@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 
 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 
 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 

Re: [DISCUSS] New Feature: Drill Client Impersonation

[Jacques Nadeau]

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 
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  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 <
> > nrentachint...@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 
> >> 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 
> >> 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
>  kbot...@maprtech.com 
>  443-718-0098
>  MapR Technologies
>  http://www.mapr.com 
> > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam 
>  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

[Keys Botzum]

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
kbot...@maprtech.com 
443-718-0098
MapR Technologies 
http://www.mapr.com 
> On Feb 22, 2016, at 4:36 PM, Neeraja Rentachintala 
>  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 
> 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  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 <
>>> nrentachint...@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 
 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 
 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
>> kbot...@maprtech.com 
>> 443-718-0098
>> MapR Technologies
>> http://www.mapr.com 
>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam 
>> wrote:
>>

Re: [DISCUSS] New Feature: Drill Client Impersonation

[Neeraja Rentachintala]

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 
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  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 <
> > nrentachint...@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 
> >> 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 
> >> 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
>  kbot...@maprtech.com 
>  443-718-0098
>  MapR Technologies
>  http://www.mapr.com 
> > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam 
>  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

[Sudheesh Katkam]

“… 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  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 <
> nrentachint...@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 
>> 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 
>> 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
 kbot...@maprtech.com 
 443-718-0098
 MapR Technologies
 http://www.mapr.com 
> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam 
 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

[Jacques Nadeau]

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 <
nrentachint...@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 
> 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 
> 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
> > > kbot...@maprtech.com 
> > > 443-718-0098
> > > MapR Technologies
> > > http://www.mapr.com 
> > > > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam 
> > > 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

[Neeraja Rentachintala]

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  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  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
> > kbot...@maprtech.com 
> > 443-718-0098
> > MapR Technologies
> > http://www.mapr.com 
> > > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam 
> > 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

[Keys Botzum]

A good suggestion. Pooling is going to important for performance.

Keys
___
Keys Botzum 
Senior Principal Technologist
kbot...@maprtech.com 
443-718-0098
MapR Technologies 
http://www.mapr.com 
> On Feb 21, 2016, at 8:11 PM, Jacques Nadeau  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  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  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
>>> kbot...@maprtech.com 
>>> 443-718-0098
>>> MapR Technologies
>>> http://www.mapr.com 
 On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam 
>>> 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

[Jacques Nadeau]

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  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  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
>> kbot...@maprtech.com 
>> 443-718-0098
>> MapR Technologies
>> http://www.mapr.com 
>> > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam 
>> 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

[Jacques Nadeau]

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  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
> kbot...@maprtech.com 
> 443-718-0098
> MapR Technologies
> http://www.mapr.com 
> > On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam 
> 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

[Keys Botzum]

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
kbot...@maprtech.com 
443-718-0098
MapR Technologies 
http://www.mapr.com 
> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam  wrote:
> 
> Hey y’all,
> 
> I plan to work on DRILL-4281 
> : support for 
> inbound/client impersonation. Please review the design document 
> ,
>  which is open for comments. There is also a link to proof-of-concept 
> (slightly hacky).
> 
> Thank you,
> Sudheesh