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

["Peter Somogyi (Jira)" <ji...@apache.org>]

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

Peter Somogyi commented on HBASE-23330:
---------------------------------------

This change adds getClusterId to the Connection interface which is annotated with IA.Public. This is breaking downstream implementations, including hbase-connectors builds with 2.4.14-SNAPSHOT. Would it be possible to add a default implementation? 

>   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-alpha-1
>            Reporter: Bharath Vissapragada
>            Assignee: Bharath Vissapragada
>            Priority: Major
>             Fix For: 3.0.0-alpha-1, 1.7.0, 2.5.0, 2.4.14
>
>
> 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.20.10#820010)