ZooKeeper的Client-Server互认证机制是从3.4.0版本开始引入的，本文主要介绍znodes的ACL的定义，任务服务接口定义与几种已有的认证服务实现，以及ACL与多种认证服务是如何建立联系的。本文内容基于ZooKeeper 3.5.1版本。
ACL
ZooKeeper的ACL可针对znodes设置相应的权限信息。ACL数据的表示格式为：schema:id:permissions
- schema 支持的几种schema为：
- world
只有一个名为
anyone的Id,world:anyone代表任何人，也就是说，对应节点任何人可访问- auth
代表任何通过认证的用户，该schema不需要配置
Id信息- digest
基于
username:password生成的MD5 Hash值作为Id信息，认证基于username:password明文认证，但在acl中存储的是username:base64(password)- ip
基于IP地址作为
Id，支持IP地址或IP地址段 - id 代表用户
- permissions 权限定义为(READ, WRITE, CREATE, DELETE, ADMIN, ALL)
znodes来提供不同的认证机制。
AuthenticationProvider
每一种认证服务均需要实现AuthenticationProvider接口来支持一种新的schema，所有的AuthenticationProvider实现类都被注册在ProviderRegistry中。ZooKeeper中已经提供的AuthenticationProvider`的实现类：
每一个AuthenticationProvider实现类所关联的schema如下所示：
| AuthenticationProvider实现类 | schema |
|---|---|
| DigestAuthenticationProvider | digest |
| IPAuthenticationProvider | ip |
| SASLAuthenticationProvider | sasl |
| X509AuthenticationProvider | x509 |
当znode acl schema为world时，是不需要经任何AuthenticationProvider进行认证的，因此不需要任何实现类。
当znode acl schema为auth时，代表着需要对请求上下文中的认证信息进行校验，在ServerCnxn的authInfo中保存了所有的已认证成功的Id以及认证服务所关联的的schema，由该schema再去ProviderRegistry中查找所关联的AuthenticationProvider实现类来对认证信息进行校验。
除了上述已有的实现者以外，用户还可以自定义实现AuthenticationProvider。自定义的实现类，需要设置到System Properties中，对应的Property Key需以"zookeeper.authProvider."开头。另外，自定义的AuthenticationProvider的schema名称不应与现有的重名，否则会覆盖现有的实现。
Reference
本文源自：NoSQL漫谈(nosqlnotes.com)
除非特别注明，本站文章均为原创，转载请注明出处和链接。