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:[email protected]] Sent: Tuesday, February 23, 2016 8:49 AM To: [email protected] Cc: dev <[email protected]> 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 <[email protected]> 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 > <[email protected]> > 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 <[email protected]> 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 < >>> [email protected]> 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 >>>> <[email protected]> >>>> 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 >>>>> <[email protected]> >>>> 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 >>>>>> [email protected] <mailto:[email protected]> >>>>>> 443-718-0098 >>>>>> MapR Technologies >>>>>> http://www.mapr.com <http://www.mapr.com/> >>>>>>> On Feb 19, 2016, at 4:49 PM, Sudheesh Katkam >>>>>>> <[email protected]> >>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >> >>
