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 [email protected] <mailto:[email protected]> 443-718-0098 MapR Technologies http://www.mapr.com <http://www.mapr.com/> > On Feb 22, 2016, at 4:36 PM, Neeraja Rentachintala > <[email protected]> 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 <[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 >>>>>> >>>>>> >>>>> >>>> >> >>
