ZK ACL access control processing process

ZK to the Znode operation using ACL access control, similar to the read and write permissions provided by Linux, ZK will operate the following categories: Create/read/write/delete/admin,

· Create: Indicates that a permission is created for a child node

· READ: means can getdata or GetChildren

· WRITE: Indicates that you can SetData

· Delete: Indicates that you can DELETE child nodes

· ADMIN: Indicates that Znode permissions can be set by SetACL

The Create and delete permissions are split from the Write permission, noting the difference from write in Linux. ZK uses constant classes to indicate these permissions.

Associating these permissions with a series of IDs constitutes a node's ACL control, so you can see the mapping relationship.

Acl=permßàid

The ID consists of scheme and the actual string ID. Scheme represents the authentication scheme identifier corresponding to the actual string ID, that is, when authenticating a string ID, it is necessary to find a corresponding authentication service provider based on scheme to authenticate the ID, such as Scheme=digest id=qingxu:pwd , which indicates that the Digest keyword corresponds to the certification service provider to authenticate the QINGXU:PWD,

ZK provides two providers based on client-side IP (SCHEME=IP) and digest-based (sha1,scheme=digest) user passwords, both of which implement the Authenticationprovider interface, Users can also increase the number of other user-defined authorizations by setting system properties that begin with Zookeeper.authprovider. (Providerregistry loads the custom authorization method when initializing). On the ZK service side, the authorization provider resides in memory in a hashmap manner, and the key is Scheme,value is the implementation class of the Authenticationprovider interface, so that the Authenticationprovider Getprovider (String scheme) will be able to obtain specific authentication services.

When the client prepares to create the Znode, the Create method requires that a list of ACLs on this znode be specified, indicating who (ID) can take some action (perm) after a certain authentication method (scheme).

public string Create (final String path,byte data[], list<acl> ACL,

Createmode Createmode)

You can use multiple ACLs on a znode, and when the server-side creates a node, it associates the ACL list with the Znode, and then persists to snapshot at a later time, when the client operates on the node or child node, Checks whether the client on the current connection has permission to manipulate the node and throws no Auth exception if there is no permission. For some permissions authentication information, the client does not need to pass the additional information to the server, for example anyone, means anyone, for similar Digest authentication service, because needs the client to provide the user password, then with the service end user password verifies (the user password combination is considered to be a user ID , where the client enters the authentication service by adding the corresponding authentication information (such as a user's password) through the client ZK Addauthinfo (for example, the username), the authentication information is passed to the server side for some processing ( Mainly is the scheme server is supported, for scheme=digest is mainly to determine whether the super Super User login to come, Scheme=ip on a simple record of the current login IP), and saved in the Authinfo this client list, This authentication information can be used all the time after this connection.

The service-side process after Addauthinfo is as follows:

The Checkacl () process for the server when the permissions are checked by the node is as follows:

Super users can do anything without permission (perm comparison).

Otherwise, the user is compared to the permissions that are required for the current operation to perm the same permissions as the Znode has. If it is inconsistent with all the aclperm on the Znode, it means that the noauthexception exception is thrown without a checksum.

If the node ACL is accessible to anyone (Shceme=world and Id=anyone), verify directly, otherwise, find the authentication service provider according to scheme, The authinfo is then looked up from the same scheme equal to the ID also match of the ACL, find the authentication pass. If all is not validated through, throw the Noauthexception

Finally: If the ZK server does not want to CHECKACL, then the server System Properties Zookeeper.skipacl=yes.