[
https://issues.apache.org/jira/browse/ZOOKEEPER-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated ZOOKEEPER-3959:
--------------------------------------
Labels: pull-request-available (was: )
> Allow multiple superUsers with SASL
> -----------------------------------
>
> Key: ZOOKEEPER-3959
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3959
> Project: ZooKeeper
> Issue Type: New Feature
> Components: server
> Affects Versions: 3.6.2
> Reporter: Damien Diederen
> Assignee: Damien Diederen
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We would like to add support for multiple SASL-authenticated {{super}} users
> to ZooKeeper.
> There currently exists a {{zookeeper.superUser}} property which is documented
> as:
> {quote}
> When this parameter is set to a [SASL] principal name, only an authenticated
> client with that principal will be able to bypass ACL checking and have full
> privileges to all znodes.
> {quote}
> Connections with an ID matching that property receive {{super}} powers
> [through somewhat "hardcoded"
> logic|https://github.com/apache/zookeeper/blob/c47ef905e077184bc5b7f555a3e2dfeb6dc046e1/zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java#L1675-L1678]
> which only admits a single principal name.
> Our goals could simply be achieved by promoting the equality comparison to a
> set membership test, and either:
> # defining a new {{zookeeper.superUsers}} property holding a comma-separated
> list of principal names, or
> # overloading {{zookeeper.superUser}}, parsing it as a comma-separated list.
> Another possibility, more complex but also more flexible, would be to
> implement the solution suggested [in this {{SASLAuthenticationProvider}}
> comment|https://github.com/apache/zookeeper/blob/fe940cdd8fb23ba09684cefb73233d570f4a20fa/zookeeper-server/src/main/java/org/apache/zookeeper/server/auth/SASLAuthenticationProvider.java#L30-L36]:
> {quote}
> TODO: consider substituting current implementation of direct ClientCnxn
> manipulation with a call to this method
> (SASLAuthenticationProvider:handleAuthentication()) at session initiation.
> {quote}
> This would allow plugging arbitrary subclasses of
> {{SASLAuthenticationProvider}} (or, possibly, implementations of a new,
> ad-hoc interface) carrying custom logic.
> Of course, these solutions are not exclusive: it would be possible to first
> implement the {{zookeeper.superUsers}} functionality in place, and to later
> migrate it to an {{AuthenticationProvider}}. E.g., doing the former in the
> 3.6 branch and reserving the latter for 3.7/{{master}}.
> What do you think?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
