Process of zk acl Access Control

ZK uses ACL to control access to znode operations. Similar to the read and write permissions provided by Linux, ZK divides the operation permissions into the following types: Create/read/write/delete/admin,

·Create: Indicates you have the permission to create a subnode.

·Read: Getdata or getchildren

·Write: Setdata is supported.

·Delete: Indicates that subnodes can be deleted.

·Admin: Sets znode permissions through setacl.

The create and delete permissions are split from the write permissions. Note the difference with the write permission in Linux. ZK uses constant classes to indicate these permissions.

Associating these permissions with a series of IDS constitutes the node ACL control pair. You can see this ing relationship.

ACL = perm ß à ID

The ID consists of scheme and the actual string ID. Scheme indicates the authentication scheme identifier corresponding to the actual string ID. That is to say, when you authenticate the string ID, you need to find the corresponding authentication service provider based on scheme to verify and authenticate the ID, for example, scheme = digest id = qingxu: Pwd indicates the certification service provider corresponding to the digest keyword to authenticate qingxu: Pwd,

ZK provides two providers: client-based IP address (scheme = IP) and digest-based (sha1, scheme = Digest) User Password. They all implement the authenticationprovider interface, you can also set zookeeper. authprovider. to add custom authorization methods (providerregistry loads custom authorization methods during initialization ). On the zk server, authorize the provider to reside in the memory in the form of hashmap, the key is scheme, and the value is the implementation class of the authenticationprovider interface, so that the authenticationprovider
Getprovider (string Scheme) can get the specific authentication service.

When the client is preparing to create a znode, the create method requires that you specify the ACL list for the znode, indicating who (ID) uses a certain authentication method (scheme) and then can take some operation (Perm ).

Public string create (final string path, byte data [], list <ACL> ACL,

Createmode)

Multiple ACLs can be used for a znode. When a node is created on the server side, the ACL list is associated with the znode and persisted to snapshot at a later time, when the client operates on this node or subnode, it checks whether the client currently connected has the permission to operate on this node. If there is no permission, a no auth exception is thrown. For some permission authentication information, the client does not need to transmit additional information to the server, such as anyone, which indicates anyone. For digest-like authentication services, the client must provide the user password, then it is verified with the user password of the server (the user password is considered a user ID in combination). The client enters the authentication service through the addauthinfo (string
Scheme, byte auth []) method to add the corresponding authentication information (such as the user password), the authentication information will be transmitted to the server for some processing (mainly whether the scheme server supports, for scheme = digest, it is mainly used to determine whether the Super User has logged on. scheme = IP simply records the current logon IP address) and stores it in the authinfo client list, this authentication information will be available for later connections.

The server process after addauthinfo is as follows:

The checkacl () process is as follows when the server checks the node's permissions:

The Super User passes through the API directly without any permissions (Perm comparison) and can perform any operations.

Otherwise, when the perm permission required for the current operation is the same as that of znode, the user is compared. If it is inconsistent with all aclperm on znode, it indicates that the verification fails and a noauthexception is thrown.

If the node ACL is accessible to anyone (shceme = World and ID = anyone), it passes verification. Otherwise, the authentication service provider is found based on scheme, then, search for the ACL with the same ID and match with the scheme in authinfo. If the ACL is found, the authentication succeeds. If none of them pass the verification, A noauthexception is thrown.

Finally, if the zk server does not want to perform checkacl, the server system attribute zookeeper. skipacl = yes.