Uploaded image for project: 'ZooKeeper'
  1. ZooKeeper
  2. ZOOKEEPER-2937

zookeeper issues with handling authentication...

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Patch Available
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.4.6
    • Fix Version/s: 3.4.6
    • Component/s: server
    • Labels:
      None
    • Environment:

      Description

      we have created an authentication provider plugin that can authenticate clients based on the cert that client is presenting. our zookeeper instance has been configured (and started) to authenticate and allow only certain appid's. this works as intended when clients (ours are c-clients) send an auth message via yca_add_auth containing the cert and the authentication provider is configured to allow it.

      however, if the clients do not present one (i.e. do not send an auth packet), and if the authentication provider allows only certain appid's, this connection still goes through - i.e. clients are able to connect, create/watch nodes etc.! this is unexpected and does not allow us to prevent certain clients from connecting to a zookeeper quorum (as they can still connect without present any credentials).

      it looks like zookeeper will only invoke the auth providers if it receives an auth packet from the client.

      none of this block - https://github.com/sriramch/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java#L1060

      ever gets executed, and it directly jumps to this

      https://github.com/sriramch/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java#L1108

      we have a usecase where we only want clients that can present valid credentials to connect to zookeeper (zk).

      i was hoping to expose an interface where different auth providers (when they are loaded) would let zk know if they need to authenticate a client before processing other data packets. the default ones (kerberos/ip/digest etc.) would say no to maintain compatibility. our auth provider can be configured to say yes/no (default no) depending on use-case. zk before processing a data packet can look at the auth info in the server connection to see the schemes that requires authentication and have successfully authenticated. connection will succeed if all schemes that require authentication have successfully authenticated; else, we disable receive.

      can someone please look into this issue and evaluate the proposal? i can work on creating a pr for this.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                sriramch Sriram Chandramouli
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: