12.2. Default Groups
A user's privileges are determined by the group (role) membership of the user. There are three groups (roles) that a user can be assigned to:
- Administrators. This group is given full access to all of the tasks available in the administrative interface.
- Agents. This group is given full access to all of the tasks available in the agent services interface.
- Auditors. This group is given access to view the signed audit logs. This group does not have any other privileges.
There is a fourth role that is exclusively created for communication between subsystems. Administrators should never assign a real user to such a role:
- Enterprise administrators. Each subsystem instance is automatically assigned a subsystem-specific role as an enterprise administrator when it is joined to a security domain during configuration. These roles automatically provide trusted relationships among subsystems in the security domain, so that each subsystem can efficiently carry out interactions with other subsystems.
Administrators have permissions to perform all administrative tasks. A user is designated or identified as being an administrator by being added to the
Administratorsgroup for the group. Every member of that group has administrative privileges for that instance of Certificate System.
At least one administrator must be defined for each Certificate System instance, but there is no limit to the number of administrators an instance can have. The first administrator entry is created when the instance is configured.
Administrators are authenticated with a simple bind using their Certificate System user ID and password.
Table 12.1. Security Domain User Roles
|Security Domain Administrators|| |
By default, the CA administrator of the CA hosting the domain is assigned as the security domain administrator.
|Enterprise CA Administrators|| |
|Enterprise KRA Administrators|| |
|Enterprise OCSP Administrators|| |
|Enterprise TKS Administrators|| |
|Enterprise TPS Administrators|| |
As necessary, the security domain administrator can manage access controls on the security domain and on the individual subsystems. For example, the security domain administrator can restrict access so that only finance department KRA administrators can set up finance department KRAs.
Enterprise subsystem administrators are given enough privileges to perform operations on the subsystems in the domain. For example, an enterprise CA administrator has the privileges to have sub-CA certificates approved automatically during configuration. Alternatively, a security domain administrator can restrict this right if necessary.
An auditor can view the signed audit logs and is created to audit the operation of the system. The auditor cannot administer the server in any way.
An auditor is created by adding a user to the
Auditorsgroup and storing the auditor's certificate in the user entry. The auditor's certificate is used to encrypt the private key of the key pair used to sign the audit log.
Auditorsgroup is set when the subsystem is configured. No auditors are assigned to this group during configuration.
Agents are users who have been assigned end-entity certificate and key-management privileges. Agents can access the agent services interface.
Agents are created by assigning a user to the appropriate subsystem agent group and identifying certificates that the agents must use for TLS client authentication to the subsystem for it to service requests from the agents. Each subsystem has its own agent group:
- The Certificate Manager Agents group.
- The Key Recovery Authority Agents group.
- The Online Certificate Status Manager Agents group.
- The Token Key Service Agents group.
- The Token Processing System Agents group.
Each Certificate System subsystem has its own agents with roles defined by the subsystem. Each subsystem must have at least one agent, but there is no limit to the number of agents a subsystem can have.
Certificate System identifies and authenticates a user with agent privileges by checking the user's TLS client certificate in its internal database.
12.2.4. Enterprise Groups
No real user should ever be asigned to this group.
During subsystem configuration, every subsystem instance is joined to a security domain. Each subsystem instance is automatically assigned a subsystem-specific role as an enterprise administrator. These roles automatically provide trusted relationships among subsystems in the security domain, so that each subsystem can efficiently carry out interactions with other subsystems. For example, this allows OCSPs to push CRL publishing publishing information to all CAs in the domain, KRAs to push KRA connector information, and CAs to approve certificates generated within the CA automatically.
Enterprise subsystem administrators are given enough privileges to perform operations on the subsystems in the domain. Each subsystem has its own security domain role:
- Enterprise CA Administrators
- Enterprise KRA Administrators
- Enterprise OCSP Administrators
- Enterprise TKS Administrators
- Enterprise TPS Administrators
Additionally, there is a Security Domain Administrators group for the CA instance which manages the security domain, access control, users, and trust relationships within the domain.
Each subsystem administrator authenticates to the other subsystems using TLS client authentication with the subsystem certificate issued during configuration by the security domain CA.