493
Appendix D. ACL Reference
This section describes what each resource controls, lists the possible operations describing the
outcome of those operations, and provides the default ACIs for each ACL resource defined. Each
subsystem contains only those ACLs that are relevant to that subsystem.
D.1. About ACL Configuration Files
Access control
is the method to set rules on who can access part of a server and the operations that
that user can perform. The four subsystems which depend on the LDAP directory service and use a
Java console — the CA, DRM, OCSP, and TKS — all implement LDAP-style access control to access
their resources. These
access control lists
(ACLs) are located in the
acl.ldif
files in the instance's
/var/lib/
subsystem_name
/conf
directory.
NOTE
This section provides only a very brief overview of access control concepts. Access
control is described in much more detail in
chapter 6, "Managing Access Control,"
1
in the
Red Hat Directory Server 8.1
Administrator's Guide
.
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
Example D.1. Default ACL to List Certificate Profiles
Because each subsystem (CA, DRM, 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, than 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.
Summary of Contents for CERTIFICATE SYSTEM 8.0 - ADMINISTRATION
Page 42: ...20 ...
Page 43: ...Part I Setting up Certificate Services ...
Page 44: ......
Page 190: ...168 ...
Page 208: ...186 ...
Page 223: ...Part II Additional Configuration to Manage CA Services ...
Page 224: ......
Page 256: ...234 ...
Page 270: ...248 ...
Page 280: ...258 ...
Page 292: ...270 ...
Page 293: ...Part III Managing the Subsystem Instances ...
Page 294: ......
Page 408: ...386 ...
Page 438: ...416 ...
Page 439: ...Part IV References ...
Page 440: ......
Page 503: ...Netscape Defined Certificate Extensions Reference 481 OID 2 16 840 1 113730 13 ...
Page 504: ...482 ...
Page 556: ...534 ...
Page 564: ...542 ...