[ https://issues.apache.org/jira/browse/HBASE-25051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398980#comment-17398980 ]
Bharath Vissapragada edited comment on HBASE-25051 at 8/13/21, 11:11 PM: ------------------------------------------------------------------------- I think one way to fix this problem is to "advertise" the cluster ID as a part of channel setup. This is an IPC protocol change. Currently the way connection setup works is 1. client to server: socket connect() 2. client sends a connection preamble (validated on server and connection closed if malformed) 3. client optionally does a sasl handshake (if configured) (3) is where cluster ID is needed (if token is configured as a part of DIGEST based auth). Now my proposal is to modify it as follows. 1. client to server: socket connect() 2. server responds with a 16 byte UUID that is read by the client (client can get the actual SASL mode with this clusterId info and looking up the tokens) 3. client sends a connection preamble (validated on server and connection closed if malformed) 4. client optionally does a sasl handshake (using the sasl and token from step(2)). A sample implementation using netty IPC is something like this https://github.com/bharathv/hbase/commit/95ff0d65828e8459d212e6173c00648b9c7b6814 . The patch still needs to do the following, 1. Move providers.selectProvider(clusterId, ticket) .. to after step (2) 2. Implement an equivalent change in Blocking IPC. One problem I can think of is compatibility between old client and new server (say during a rolling upgrade when server is upgraded first), I can see if I can get it working by making client ignore this piece of response. cc: [~zhangduo] WDYT. You think this breaks anything else too or is there a better way? was (Author: bharathv): I think one way to fix this problem is to "advertise" the cluster ID as a part of channel setup. This is an IPC protocol change. Currently the way connection setup works is 1. client to server: socket connect() 2. client sends a connection preamble (validated on server and connection closed if malformed) 3. client optionally does a sasl handshake (if configured) (3) is where cluster ID is needed (if token is configured as a part of DIGEST based auth). Now my proposal is to modify it as follows. 1. client to server: socket connect() 2. server responds with a 16 byte UUID that is read by the client (client can get the actual SASL mode with this clusterId info and looking up the tokens) 2. client sends a connection preamble (validated on server and connection closed if malformed) 3. client optionally does a sasl handshake (using the sasl and token from step(2)). A sample implementation using netty IPC is something like this https://github.com/bharathv/hbase/commit/95ff0d65828e8459d212e6173c00648b9c7b6814 . The patch still needs to do the following, 1. Move providers.selectProvider(clusterId, ticket) .. to after step (2) 2. Implement an equivalent change in Blocking IPC. One problem I can think of is compatibility between old client and new server (say during a rolling upgrade when server is upgraded first), I can see if I can get it working by making client ignore this piece of response. cc: [~zhangduo] WDYT. You think this breaks anything else too or is there a better way? > DIGEST based auth broken for MasterRegistry > ------------------------------------------- > > Key: HBASE-25051 > URL: https://issues.apache.org/jira/browse/HBASE-25051 > Project: HBase > Issue Type: Sub-task > Components: Client, security > Affects Versions: 3.0.0-alpha-1, 2.3.0, 1.7.0 > Reporter: Bharath Vissapragada > Assignee: Bharath Vissapragada > Priority: Minor > > DIGEST-MD5 based sasl auth depends on cluster-ID to obtain tokens. With > master registry, we have a circular dependency here because master registry > needs an rpcClient to talk to masters (and to get cluster ID) and rpc-Client > needs a clusterId if DIGEST based auth is configured. Earlier, there was a ZK > client that has its own authentication mechanism to fetch the cluster ID. > HBASE-23330, I think doesn't fully fix the problem. It depends on an active > connection to fetch delegation tokens for the MR job and that inherently > assumes that the active connection does not use a DIGEST auth. > It is not clear to me how common it is to use DIGEST based auth in > connections. -- This message was sent by Atlassian Jira (v8.3.4#803005)