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 > > > > > > > > >
