ZooKeeper
  1. ZooKeeper
  2. ZOOKEEPER-1634

A new feature proposal to ZooKeeper: authentication enforcement

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.4.5
    • Fix Version/s: 3.5.0
    • Component/s: server
    • Labels:
      None
    • Tags:
      authentication

      Description

      Up to the version of 3.4.5, ZooKeeperServer doesn't force the authentication if the client doesn't give any auth-info through ZooKeeper#addAuthInfo method invocation. Hence, every znode should have at least one ACL assigned otherwise any unauthenticated client can do anything on it.

      The current authentication/authorization mechanism of ZooKeeper described above has several points at issue:
      1. At security standpoint, a maleficent client can access a znode which doesn't have any proper authorization access control set.
      2. At runtime performance standpoint, authorization for every znode to every operation is unnecessarily but always evaluated against the client who bypassed the authentication phase.

      In other words, the current mechanism doesn't address a certain requirement at below:
      "We want to protect a ZK server by enforcing a simple authentication to every client no matter which znode it is trying to access. Every connection (or operation) from the client won't be established but rejected if it doesn't come with a valid authentication information. As we don't have any other distinction between znodes in term of authorization, we don't want any ACLs on any znode."

      To address the issues mentioned above, we propose a feature called "authentication enforcement" to the ZK source. The idea is roughly but clearly described in a form of patch in the attached file (zookeeper_3.4.5_patch_for_authentication_enforcement.patch): which makes ZooKeeperServer enforce the authentication with the given 2 configurations: authenticationEnforced (boolean) and enforcedAuthenticationScheme (string) against every operation coming through ZooKeeperServer#processPacket method except for OpCode.auth operation. The repository base of the patch is "http://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.5/"

        Activity

        Hide
        Jaewoong Choi added a comment -

        This patch is incomplete meaning not directly applicable but I believe it's enough showing the idea of the proposal.

        Show
        Jaewoong Choi added a comment - This patch is incomplete meaning not directly applicable but I believe it's enough showing the idea of the proposal.
        Hide
        Patrick Hunt added a comment -

        Why wouldn't we just implement SSL encryption on the client-server pipes and then use bi-di certs for authentication? There's a long standing patch to add netty support for client-server communication, which would simplify this (adding netty ssl support to that is trivial).

        Show
        Patrick Hunt added a comment - Why wouldn't we just implement SSL encryption on the client-server pipes and then use bi-di certs for authentication? There's a long standing patch to add netty support for client-server communication, which would simplify this (adding netty ssl support to that is trivial).
        Hide
        Alex Guan added a comment -

        I believe the idea is to reuse the the existing authentication framework which is extensible and much more flexible than just providing ssl based authentication.

        Show
        Alex Guan added a comment - I believe the idea is to reuse the the existing authentication framework which is extensible and much more flexible than just providing ssl based authentication.
        Hide
        Jaewoong Choi added a comment -

        SSL is simply just overburden for the given authentication requirement both for service and client sides where there's no any need of channel security for both sides.

        Show
        Jaewoong Choi added a comment - SSL is simply just overburden for the given authentication requirement both for service and client sides where there's no any need of channel security for both sides.
        Hide
        Jaewoong Choi added a comment -

        To clarify, both client and server don't care about chances of eavesdropping or tampering of communication. Assume the situation that communication doesn't include any data should be secured. Only server cares about the authentication of the client so that it can't deny unidentified connection during the authentication phase efficiently in one shot. In this requirement, why would we encrypt all data packets with cost at socket layer? SSL may can be considered but separately only if there comes a need of channel security. Totally different requirement.

        Show
        Jaewoong Choi added a comment - To clarify, both client and server don't care about chances of eavesdropping or tampering of communication. Assume the situation that communication doesn't include any data should be secured. Only server cares about the authentication of the client so that it can't deny unidentified connection during the authentication phase efficiently in one shot. In this requirement, why would we encrypt all data packets with cost at socket layer? SSL may can be considered but separately only if there comes a need of channel security. Totally different requirement.

          People

          • Assignee:
            Unassigned
            Reporter:
            Jaewoong Choi
          • Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 72h
              72h
              Remaining:
              Remaining Estimate - 72h
              72h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development