> 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#BABEJEIA >>>>> >>>>> -- >>>>> 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/1g0KgugVdRbbIxxZrSCtO1PEHlvwczTLDb38k-npvwjA >>>>>> , >>>>>> which is open for comments. There is also a link to proof-of-concept >>>>>> (slightly hacky). >>>>>>> >>>>>>> Thank you, >>>>>>> Sudheesh >>>>>> >>>>>> >>>>> >>>> >> >>
