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