Re: [DISCUSS] New Feature: Drill Client Impersonation

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 <d.

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

Re: [DISCUSS] New Feature: Drill Client Impersonation

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,

Re: [DISCUSS] New Feature: Drill Client Impersonation

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

Re: [DISCUSS] New Feature: Drill Client Impersonation

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

Re: [DISCUSS] New Feature: Drill Client Impersonation

“… 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

Re: [DISCUSS] New Feature: Drill Client Impersonation

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

Re: [DISCUSS] New Feature: Drill Client Impersonation

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

Re: [DISCUSS] New Feature: Drill Client Impersonation

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

Re: [DISCUSS] New Feature: Drill Client Impersonation

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

Re: [DISCUSS] New Feature: Drill Client Impersonation

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

[DISCUSS] New Feature: Drill Client Impersonation

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