From issues-return-504-archive-asf-public=cust-asf.ponee.io@zookeeper.apache.org Tue Jul 30 16:50:03 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id C7B1B180644 for ; Tue, 30 Jul 2019 18:50:02 +0200 (CEST) Received: (qmail 76597 invoked by uid 500); 30 Jul 2019 16:50:01 -0000 Mailing-List: contact issues-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@zookeeper.apache.org Delivered-To: mailing list issues@zookeeper.apache.org Received: (qmail 76524 invoked by uid 99); 30 Jul 2019 16:50:01 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jul 2019 16:50:01 +0000 Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id CEA3AE2F87 for ; Tue, 30 Jul 2019 16:50:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 32EAB26638 for ; Tue, 30 Jul 2019 16:50:00 +0000 (UTC) Date: Tue, 30 Jul 2019 16:50:00 +0000 (UTC) From: "Michael Han (JIRA)" To: issues@zookeeper.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ZOOKEEPER-3476) Identify client request for quota control MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ZOOKEEPER-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896317#comment-16896317 ] Michael Han commented on ZOOKEEPER-3476: ---------------------------------------- The design looks good to me. I have a patch that supports explicitly specifying client id as a string from user. It does not require auth though, which means a malicious user could impersonate another user thus potentially compromise the quota throttling. Though, in our environment, we think all our clients are trustable and this is not a problem for us. This might be useful for use cases where users don't want to enable auth. This JIRA seems imply that to support client-id, authentication must be enabled. Do we want to enforce this moving forward, or do we also want to support client-id without authentication (for use case in a "trustable" environment)? > Identify client request for quota control > ----------------------------------------- > > Key: ZOOKEEPER-3476 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3476 > Project: ZooKeeper > Issue Type: Sub-task > Components: server > Reporter: Mocheng Guo > Priority: Major > > In order to support quota, we need a way to identify clients. If security is enabled, we might be able to use secured identity inside client certificate. But a generalized client-id based approach would be better to cover scenario without security. > The proposal here is to utilize existing zookeeper auth protocol to accept client identity. > # The client id should be sent by client once connection is established. > # Sending client id is optional. Note that server needs to enable auth provider if client does send in client id auth request or request would be denied without auth provider on server side. > # client id is JSON withe client_id as mandatory field. Additional fields can be added like client contact information, client version... > # This client identity will be cached in server connection and attached to requests from the connection. -- This message was sent by Atlassian JIRA (v7.6.14#76016)