[ 
https://issues.apache.org/jira/browse/DRILL-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15179096#comment-15179096
 ] 

ASF GitHub Bot commented on DRILL-4281:
---------------------------------------

Github user jacques-n commented on the pull request:

    https://github.com/apache/drill/pull/400#issuecomment-192046477
  
    Generally looks good. +1 with the few small items above addressed. Updating 
the names to something else would be good. Since this is also impersonation 
(just client impersonation instead of storage plugin impersonation) I'm not 
sure I would shy away from using the term. The main goal for me is clear 
directionality. I think "principals" works well for the first piece. Ideas for 
the second:
    "can_execute_as", "can_impersonate", "can_act_as", ?



> Drill should support inbound impersonation
> ------------------------------------------
>
>                 Key: DRILL-4281
>                 URL: https://issues.apache.org/jira/browse/DRILL-4281
>             Project: Apache Drill
>          Issue Type: Improvement
>            Reporter: Keys Botzum
>            Assignee: Sudheesh Katkam
>              Labels: doc-impacting, security
>
> Today Drill supports impersonation *to* external sources. For example I can 
> authenticate to Drill as myself and then Drill will access HDFS using 
> impersonation
> In many scenarios we also need impersonation to Drill. For example I might 
> use some front end tool (such as Tableau) and authenticate to it as myself. 
> That tool (server version) then needs to access Drill to perform queries and 
> I want those queries to run as myself, not as the Tableau user. While in 
> theory the intermediate tool could store the userid & password for every user 
> to the Drill this isn't a scalable or very secure solution.
> Note that HS2 today does support inbound impersonation as described here:  
> https://issues.apache.org/jira/browse/HIVE-5155 
> The above is not the best approach as it is tied to the connection object 
> which is very coarse grained and potentially expensive. It would be better if 
> there was a call on the ODBC/JDBC driver to switch the identity on a existing 
> connection. Most modern SQL databases (Oracle, DB2) support such function.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to