Appendix D. ACL Reference

Access control is the method to set rules on who can access part of a server and the operations that user can perform. The four subsystems which depend on the LDAP directory service and use a Java console — the CA, KRA, OCSP, and TKS — all implement LDAP-style access control to access their resources. These access control lists (ACL) are located in the /var/lib/pki/instance_name/conf/subsystem/acl.ldif file.

The Certificate System ACL files are LDIF files that are loaded by the internal database. The individual ACLs are defined as resourceACLS attributes which identify the area of the subsystem being protected and then a list of all of the specific access controls being set.

resourceACLS: class_name:all rights: allow|deny (rights) type=target description

Each rule which allows or denies access to a resource is called an access control instruction (ACI). (The sum of all of the ACIs for a resource is an access control list.) Before defining the actual ACI, the ACL attribute is first applied to a specific plug-in class used by the Certificate System subsystem. This focuses each ACL to a specific function performed by the subsystem, providing both more security for the instance and better control over applying ACLs.

resourceACLS: certServer.ca.profiles:list:allow (list) group="Certificate Manager Agents":Certificate Manager agents may list profiles

Because each subsystem (CA, KRA, OCSP, and TKS) has different resources for its operations, each subsystem instance has its own acl.ldif file and its own defined ACLs.

Each ACI defines what access or behavior can be done (the right) and who the ACI applies to (the target). The basic format of an ACI is, then:

allow|deny (rights) user|group

Rights are types of operations that the ACI allows a user to perform. For LDAP ACIs, there is a relatively limited list of rights to directory entries, like search, read, write, and delete. The Certificate System uses additional rights that cover common PKI tasks, like revoke, submit, and assign.

If an operation is not explicitly allowed in an ACI, then it is implicitly denied. If an operation is explicitly denied in one ACI, then it trumps any ACI which explicitly allows it. Deny rules are always superior to allow rules to provide additional security.

Each ACI has to apply to specific users or groups. This is set using a couple of common conditions, usually user= or group=, though there are other options, like ipaddress= which defines client-based access rather than entry-based access. If there is more than one condition, the conditions can be composed using the double pipe (||) operator, signifying logical disjunction ("or"), and the double ampersand (&&) operator, signifying logical conjunction ("and"). For example, group="group1" || "group2".

Each area of the resourceACLS attribute value is defined in Table D.1, “Sections of the ACL Attribute Value”.