zookeeper-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Han (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-3476) Identify client request for quota control
Date Wed, 31 Jul 2019 04:40:00 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-3476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896772#comment-16896772
] 

Michael Han commented on ZOOKEEPER-3476:
----------------------------------------

My patch alters the client server protocol a little bit by adding client id related information
(id string, version, etc) to each packet. Similar to how the protocol was extended for read
only servers.

bq. The proposed authentication provider will not validate client id from client

I was thinking if authentication was enabled, we can extract the auth related information
(e.g. Kerberos principal) and use that for client id. Impersonating clients will not pass
authentication. This might not be exactly what you are referring here as the "proposed authentication
provider", but more like the TLS case you were talking about.

In any case, to prevent impersonating, we need have an identity management module that supports
login a client (we kind of have it today with SASL / TLS right?), and after client login we
can use client identification extracted from the auth info.

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

Mime
View raw message