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

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

Github user NeerajaRentachintala commented on the pull request:

    https://github.com/apache/drill/pull/400#issuecomment-192382894
  
    Folks
    Why do we need to invent new terms here. What Drill is trying to here is a
    very common use case for other tools in Hadoop eco system as well.
    Can we just pick Hadoop terminology and move on.
    
    
    -Neeraja
    
    On Fri, Mar 4, 2016 at 7:23 AM, Keys Botzum <[email protected]>
    wrote:
    
    > One suggestion. The terms I use when discussing the concepts with
    > customers are Drill inbound impersonation and Drill outbound 
impersonation.
    > That is absolutely clear. It does imply implementation to a bit but I 
think
    > makes intent very clear. You can then derive other terms from that such as
    > "can_impersonate_inbound" and
    > "principals_authorized_for_inbound_impersonation." Yea, really wording but
    > very clear. We can of course shorten to "princ_auth_inbound_imper" in 
code.
    >
    > Would that make sense?
    >
    > By the way the use of the termed chained in the context of security
    > usually implied something like chained delegation which makes me think of 
a
    > security identity that is both end to end secure like kerberos and 
includes
    > all identities that were passed through. That's not this so I'd avoid use
    > of the term chained.
    >
    > —
    > Reply to this email directly or view it on GitHub
    > <https://github.com/apache/drill/pull/400#issuecomment-192320077>.
    >



> 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