Yep, I know I've had conversations with Neeraja over that, while some JDBC databases do support it, it would have to be implemented in Drill to pass that information through to JDBC, thus work still needs to be done. The nice thing with Drill, is there are options, in how to implement these features, just need to find the resources to put the finishing touches on things.
John On Fri, Jul 29, 2016 at 10:04 AM, Keys Botzum <kbot...@maprtech.com> wrote: > I can't speak to the capabilities of MongoDB and S3 but most relational > databases (Oracle and DB2 for certain and I think SQLServer) support > impersonation over JDBC. I even wrote a paper on this: > http://www.ibm.com/developerworks/websphere/techjournal/0506_barghouthi/0506_barghouthi.html > > That paper is dated. DB2 added support after I wrote it. > > > 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 Jul 29, 2016, at 10:54 AM, John Omernik <j...@omernik.com> wrote: > > > > Keys - > > > > Thanks for the information, however, to Steve's question, there is no way > > to secure the storage plugin itself, and thus any credentials to systems > > downstream that require credentials (MongoDB, S3, JDBC, etc) can not be > > secured. There is only one user that has access to those downstream > > systems, and thus the impersonated user has no affect on the security of > > the data downstream. Even with views, there is nothing in drill that can > > prevent a user from using the storage plugin directly, and thus you have > a > > shared user, defeating accountability and limiting the ability to protect > > the confidentiality of data. > > > > John > > > > On Fri, Jul 29, 2016 at 9:08 AM, Keys Botzum <kbot...@maprtech.com > <mailto:kbot...@maprtech.com>> wrote: > > > >> Drill does use HDFS/Mapr-FS impersonation to push identity down to the > >> underlying storage system - HDFS, MapR-FS, MapR-DB. Once that is done > the > >> underlying storage system can then perform authorization. This is a > robust > >> model that is advantageous as it ensures that data is protected the same > >> way regardless of access path. It may be that there are additional > storage > >> systems which Drill does not yet impersonate to. Can you say more in > terms > >> of requirements? > >> > >> Drill impersonation: > >> https://drill.apache.org/docs/configuring-user-impersonation/ > >> > >> In addition Drill supports views which can be created and shared amongst > >> users. Basically I can create a view on data I own and share that view > with > >> others that can't see the underlying data but can see the view. > >> > >> Drill views: http://drill.apache.org/docs/create-view-command/ > >> > >> Keys > >> _______________________________ > >> Keys Botzum > >> Senior Principal Technologist > >> kbot...@maprtech.com <mailto:kbot...@maprtech.com> <mailto: > kbot...@maprtech.com <mailto:kbot...@maprtech.com>> > >> 443-718-0098 > >> MapR Technologies > >> http://www.mapr.com <http://www.mapr.com/> <http://www.mapr.com/ < > http://www.mapr.com/>> > >>> On Jul 29, 2016, at 9:50 AM, Steve Warren <swar...@myvest.com> wrote: > >>> > >>> With Drill I can authenticate a user and distinguish between ADMIN and > >>> USER. However, there doesn't seem to be much (any) in the way of per > user > >>> authorizations beyond that. Example uses being: > >>> > >>> 1) Allowing for per user AWS credentials. > >>> 2) Returning a token or other profile information from the > authentication > >>> process that can be passed into each storage plugin. > >>> 3) ACL for storage plugins (by user group). > >>> > >>> Are there any plans to extend the authorization capabilities in these > >> areas? > >>> > >>> Cheers > >>> > >>> -- > >>> Confidentiality Notice and Disclaimer: The information contained in > this > >>> e-mail and any attachments, is not transmitted by secure means and may > >> also > >>> be legally privileged and confidential. If you are not an intended > >>> recipient, you are hereby notified that any dissemination, > distribution, > >> or > >>> copying of this e-mail is strictly prohibited. If you have received > this > >>> e-mail in error, please notify the sender and permanently delete the > >> e-mail > >>> and any attachments immediately. You should not retain, copy or use > this > >>> e-mail or any attachment for any purpose, nor disclose all or any part > of > >>> the contents to any other person. MyVest Corporation, MyVest Advisors > and > >>> their affiliates accept no responsibility for any unauthorized access > >>> and/or alteration or dissemination of this communication nor for any > >>> consequence based on or arising out of the use of information that may > >> have > >>> been illegitimately accessed or altered. > >
