drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Nadeau <jacq...@dremio.com>
Subject Re: [DISCUSS] New Feature: Drill Client Impersonation
Date Mon, 22 Feb 2016 17:49:42 GMT
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 <
nrentachintala@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 <jacques@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 <kbotzum@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
> > > kbotzum@maprtech.com <mailto:kbotzum@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 <skatkam@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
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message