You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Bharath Vissapragada (Jira)" <ji...@apache.org> on 2020/01/23 01:22:00 UTC

[jira] [Commented] (HBASE-23330) Expose cluster ID for clients using it for delegation token based auth

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

Bharath Vissapragada commented on HBASE-23330:
----------------------------------------------

[~ghelmling]/[~apurtell] After staring at the code, I realized that all the calls to get a token happen *after* creating a connection . For example, look at all the callers of {{TokenUtil#getAuthToken()}} (Also, refer to TableMapReduceUtil#initCredentials() call path) . Now my point is, if we already have the connection created by then, we can use the regular "registry" way of fetching the cluster ID, no? Only case where it does not work is if the conneciton is of type {ThriftConnection}. Does anyone use delegation tokens with a ThriftConnection?

Fwiw, I figured out a way to bypass spnego authentication and implemented a servlet that can plumb the cluster ID. After doing that and fixing the actual problem, I figured that it is not actually needed at all. Did I miss something? 

>   Expose cluster ID for clients using it for delegation token based auth
> ------------------------------------------------------------------------
>
>                 Key: HBASE-23330
>                 URL: https://issues.apache.org/jira/browse/HBASE-23330
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Client, master
>    Affects Versions: 3.0.0
>            Reporter: Bharath Vissapragada
>            Assignee: Bharath Vissapragada
>            Priority: Major
>
> As Gary Helming noted in HBASE-18095, some clients use Cluster ID for delgation based auth. 
> {quote}
> There is an additional complication here for token-based authentication. When a delegation token is used for SASL authentication, the client uses the cluster ID obtained from Zookeeper to select the token identifier to use. So there would also need to be some Zookeeper-less, unauthenticated way to obtain the cluster ID as well.
> {quote}
> Once we move ZK out of the picture, cluster ID sits behind an end point that needs to be authenticated. Figure out a way to expose this to clients.
> One suggestion in the comments (from Andrew)
> {quote}
>  Cluster ID lookup is most easily accomplished with a new servlet on the HTTP(S) endpoint on the masters, serving the cluster ID as plain text. It can't share the RPC server endpoint when SASL is enabled because any interaction with that endpoint must be authenticated. This is ugly but alternatives seem worse. One alternative would be a second RPC port for APIs that do not / cannot require prior authentication.
> {quote}
> There could be implications if SPNEGO is enabled on these http(s) end points. We need to make sure that it is handled.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)