[
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)