Re: Per user authorization

[Steve Warren]

I'm not clear on what the deep complexities would be, but all I think is
needed is to be able to return custom profile data from the authentication
provider that is then passed along to the storage plugins as properties.

Cheers
Steve

On Fri, Jul 29, 2016 at 10:16 AM, Keys Botzum  wrote:

> No disagreement that for storage systems that lack the needed inbound
> impersonation that Drill might need to support other approaches such as
> managing per user credentials per storage system. I just wanted to make
> clear that Drill does provide for excellent authorization for storage
> systems that it currently impersonates to. I genuinely believe that is the
> best approach in general.
>
> That said, since Drill is trying to support many storage systems, some of
> which lack the needed functionality, that other approaches may also be
> needed.  I don't know if there is a JIRA out there for such a feature.
> Having worked with such systems in the past, I'll just caution that there
> are deep complexities around managing per user credentials.
>
> Keys
> ___
> Keys Botzum
> Senior Principal Technologist
> kbot...@maprtech.com 
> 443-718-0098
> MapR Technologies
> http://www.mapr.com 
> > On Jul 29, 2016, at 1:00 PM, Steve Warren  wrote:
> >
> > Hi Keys, S3 is a good example the authentication process could return a
> > profile that includes the S3 access credentials for this user. Another
> > example would be a mechanism such as Tableau's Web Data Connector.
> > Supporting that sort of capability would really open up the community to
> > write plugin's for Drill as it has for Tableau.
> >
> > On Fri, Jul 29, 2016 at 7:08 AM, Keys Botzum 
> 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 
> >> 443-718-0098
> >> MapR Technologies
> >> http://www.mapr.com 
> >>> On Jul 29, 2016, at 9:50 AM, Steve Warren  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.
> >>
> >>
> >
> > --
> > 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
>

Re: Per user authorization

[Keys Botzum]

No disagreement that for storage systems that lack the needed inbound 
impersonation that Drill might need to support other approaches such as 
managing per user credentials per storage system. I just wanted to make clear 
that Drill does provide for excellent authorization for storage systems that it 
currently impersonates to. I genuinely believe that is the best approach in 
general.

That said, since Drill is trying to support many storage systems, some of which 
lack the needed functionality, that other approaches may also be needed.  I 
don't know if there is a JIRA out there for such a feature.  Having worked with 
such systems in the past, I'll just caution that there are deep complexities 
around managing per user credentials.

Keys
___
Keys Botzum 
Senior Principal Technologist
kbot...@maprtech.com 
443-718-0098
MapR Technologies 
http://www.mapr.com 
> On Jul 29, 2016, at 1:00 PM, Steve Warren  wrote:
> 
> Hi Keys, S3 is a good example the authentication process could return a
> profile that includes the S3 access credentials for this user. Another
> example would be a mechanism such as Tableau's Web Data Connector.
> Supporting that sort of capability would really open up the community to
> write plugin's for Drill as it has for Tableau.
> 
> On Fri, Jul 29, 2016 at 7:08 AM, Keys Botzum  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 
>> 443-718-0098
>> MapR Technologies
>> http://www.mapr.com 
>>> On Jul 29, 2016, at 9:50 AM, Steve Warren  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.
>> 
>> 
> 
> -- 
> 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

Re: Per user authorization

[Steve Warren]

Hi Keys, S3 is a good example the authentication process could return a
profile that includes the S3 access credentials for this user. Another
example would be a mechanism such as Tableau's Web Data Connector.
Supporting that sort of capability would really open up the community to
write plugin's for Drill as it has for Tableau.

On Fri, Jul 29, 2016 at 7:08 AM, Keys Botzum  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 
> 443-718-0098
> MapR Technologies
> http://www.mapr.com 
> > On Jul 29, 2016, at 9:50 AM, Steve Warren  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.
>
>

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

Re: Per user authorization

[John Omernik]

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  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 
> 443-718-0098
> MapR Technologies
> http://www.mapr.com 
> > On Jul 29, 2016, at 10:54 AM, John Omernik  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  > 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   kbot...@maprtech.com >
> >> 443-718-0098
> >> MapR Technologies
> >> http://www.mapr.com   http://www.mapr.com/>>
> >>> On Jul 29, 2016, at 9:50 AM, Steve Warren  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.
>
>

Re: Per user authorization

[Keys Botzum]

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 
443-718-0098
MapR Technologies 
http://www.mapr.com 
> On Jul 29, 2016, at 10:54 AM, John Omernik  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  > 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  
>> >
>> 443-718-0098
>> MapR Technologies
>> http://www.mapr.com  > >
>>> On Jul 29, 2016, at 9:50 AM, Steve Warren  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.

Re: Per user authorization

[John Omernik]

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  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 
> 443-718-0098
> MapR Technologies
> http://www.mapr.com 
> > On Jul 29, 2016, at 9:50 AM, Steve Warren  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.
>
>

Re: Per user authorization

[Keys Botzum]

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 
443-718-0098
MapR Technologies 
http://www.mapr.com 
> On Jul 29, 2016, at 9:50 AM, Steve Warren  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.

Re: Per user authorization

[John Omernik]

Good question Steve.  I know I've posted some items related to securing of
storage plugins. Perhaps not using Drill itself to secure this, but instead
using a file directory and thus using filesystem permissions to store the
definitions and secure them. (The alternative is to add a znode with unix
like permissions there).  Basically using the same approach to secure
storage plugins as we use for drill views.  This would be very beneficial,
both for S3 stuff, but also for JDBC plugin stuff. There has also been some
conversation around passing credentials to the JDBC plugin to auth per
user, but no work done specifically (that I am aware of)

These are important enterprise level features that I think are very
important to the adoption of Drill.

On Fri, Jul 29, 2016 at 8:50 AM, Steve Warren  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.
>

Per user authorization

[Steve Warren]

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.