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