[jira] [Commented] (HBASE-25051) DIGEST based auth broken for MasterRegistry
[ https://issues.apache.org/jira/browse/HBASE-25051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805190#comment-17805190 ] Duo Zhang commented on HBASE-25051: --- As we support different types of ConnectionRegistry, it should be created before we have any HBase connections yet, and when creating any HBase connections, as well as the RpcClient, we need to get the cluster id from ConnectionRegistry. So here, I think the design is that, the ConnectionRegistry should have different ways for authentication, otherwise, it will have cyclic dependency, as the description said. Moving the logic for getting cluster id to rpc connection setup step completely changes the architecture, so I do not think it is easy to do. Maybe a more simplier way is to change the way on how we get cluster id in RpcConnectionRegistry, without relying on the normal rpc method call. Will try to implement a POC recently. Thanks. > 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 >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.20.10#820010)
[jira] [Commented] (HBASE-25051) DIGEST based auth broken for MasterRegistry
[ https://issues.apache.org/jira/browse/HBASE-25051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755393#comment-17755393 ] Andras Salamon commented on HBASE-25051: [~bharathv] Do you have an update for this ticket? What is the current status? > 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 >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.20.10#820010)
[jira] [Commented] (HBASE-25051) DIGEST based auth broken for MasterRegistry
[ https://issues.apache.org/jira/browse/HBASE-25051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17399002#comment-17399002 ] Duo Zhang commented on HBASE-25051: --- Negotiating authentication method through the first exchange of packets is a typical way in network protocols. So in general I think this is a possible way. Let's draw a whole picture on how we do rpc connecting first? Thanks. > 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)
[jira] [Commented] (HBASE-25051) DIGEST based auth broken for MasterRegistry
[ https://issues.apache.org/jira/browse/HBASE-25051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17398980#comment-17398980 ] Bharath Vissapragada commented on HBASE-25051: -- 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)
