You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Patrick Hunt (JIRA)" <ji...@apache.org> on 2013/02/16 02:20:12 UTC

[jira] [Commented] (ZOOKEEPER-1634) A new feature proposal to ZooKeeper: authentication enforcement

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

Patrick Hunt commented on ZOOKEEPER-1634:
-----------------------------------------

Why wouldn't we just implement SSL encryption on the client-server pipes and then use bi-di certs for authentication? There's a long standing patch to add netty support for client-server communication, which would simplify this (adding netty ssl support to that is trivial).
                
> A new feature proposal to ZooKeeper: authentication enforcement
> ---------------------------------------------------------------
>
>                 Key: ZOOKEEPER-1634
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1634
>             Project: ZooKeeper
>          Issue Type: Improvement
>          Components: server
>    Affects Versions: 3.4.5
>            Reporter: Jaewoong Choi
>             Fix For: 3.5.0
>
>         Attachments: zookeeper_3.4.5_patch_for_authentication_enforcement.patch
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> Up to the version of 3.4.5, ZooKeeperServer doesn't force the authentication if the client doesn't give any auth-info through ZooKeeper#addAuthInfo method invocation.  Hence, every znode should have at least one ACL assigned otherwise any unauthenticated client can do anything on it.
> The current authentication/authorization mechanism of ZooKeeper described above has several points at issue:
> 1. At security standpoint, a maleficent client can access a znode which doesn't have any proper authorization access control set.
> 2. At runtime performance standpoint, authorization for every znode to every operation is unnecessarily but always evaluated against the client who bypassed the authentication phase.
> In other words, the current mechanism doesn't address a certain requirement at below:
> "We want to protect a ZK server by enforcing a simple authentication to every client no matter which znode it is trying to access.  Every connection (or operation) from the client won't be established but rejected if it doesn't come with a valid authentication information.  As we don't have any other distinction between znodes in term of authorization, we don't want any ACLs on any znode."
> To address the issues mentioned above, we propose a feature called "authentication enforcement" to the ZK source.  The idea is roughly but clearly described in a form of patch in the attached file (zookeeper_3.4.5_patch_for_authentication_enforcement.patch): which makes ZooKeeperServer enforce the authentication with the given 2 configurations: authenticationEnforced (boolean) and enforcedAuthenticationScheme (string) against every operation coming through ZooKeeperServer#processPacket method except for OpCode.auth operation.  The repository base of the patch is "http://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.5/"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira