Damien Diederen created ZOOKEEPER-3959:
------------------------------------------

             Summary: 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


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)

Reply via email to