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 [email protected] <mailto:[email protected]> 443-718-0098 MapR Technologies http://www.mapr.com <http://www.mapr.com/> > On Jul 29, 2016, at 10:54 AM, John Omernik <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> 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 <[email protected]> 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.
