|[Front page] [Index]|
An SSH Tectia Certifier operator has a set of access control rights, defining what kind of operations the operator is allowed to perform. These operations can be restricted for certain kind of operations (read, entity write, write, write and key recovery, and super-user) and/or for certain CAs and RAs in the system. This enables adding administrators that are allowed to configure only one specific logical CA or RA in the system. Also, by using access control levels, lower and higher privileged operators can be added.
SSH Tectia Certifier supports the following access control levels:
- Read access
Read access for certain CA in the system means that the administrator is authorized to view any information related to the CA. However, this access control level does not allow any modification such as certification request approval, entity modifications or configuring.
- Read and revocation access
This is as read access above, but in addition the operator can suspend and revoke certificates. The operator cannot reactivate suspended certificates.
- Entity write access
With entity write access the operator is authorized to modify entities in the system. These operations include creating new entities and modifying entity information. This means that the operator can update entity contact information such as phone numbers or e-mail address. The operator can also revoke certificates belonging to the entities. However, an operator with entity write access is not allowed to create shared keys or accept certification requests.
- Write access
Write access allows editing entities, processing requests manually, and revoking and suspending valid certificates. This is an appropriate authorization level for operators who run the everyday CA/RA operations, but do not configure the system.
- Write and key recovery access
Write and key recovery access allows the same actions as write access, but in addition the operator can access escrowed private keys.
Note that this access level gives the operator access to sensitive information (user private keys), and should be given to operators only if they are required to do key recovery operations.
- Super-user access
A super user is allowed to perform any operation related to specific CA. These operations include modifying CA settings such as certificate policy and publishing schemas.
As a super user has full control over the policy of the CA and access to escrowed private keys, this access level should be used only when it is necessary.
Configuring servers and creating and updating other operators requires Super-user access to ALL CAs.
There are four drop-down menus in the Edit Access Control Item page. The first one defines the Access level as described above (No access, Read access, Read and revocation access, Entity write access, Write access, Write and key recovery access, or Super-user access).
The second menu (Target CA) can be used to select to which CA the access control is applicable. If the -EVERY CA- option is selected, the operator is authorized to access all logical CAs in the system.
The third menu (Rule scope) can be used to decide whether also subordinate CAs of the selected CA are included in the authorization.
The fourth menu can be used to set additional Constraints that limit the operator's rights only to those certificates or entities that match the given criteria.
Two types of constraints can be used. These are Certificate/request field match and Entity attribute match. Both constraint types contain an additional selection, for the Certificate field and Entity attribute, respectively.
To add a constraint, select the type from the list and click Add. Select the constraint from the list and enter the pattern to be matched in the text box. Several constraints can be added.
To remove a constraint, click Remove next to it.
Example: Email is selected as the Entity attribute constraint, and the pattern is the following:
The entity must have the Email attribute
firstname.lastname@example.org for the operator's access control item to match.
Entity constraints are verified when the operator manages an entity and also when the operator edits a request or a certificate belonging to an entity.
Certificate constrains are verified only when the operator manages a request or a certificate.
The constrains are regular expressions and they are not required to match the whole string. For example, the constraint '
ssh' would match the string '
email@example.com'. If you want to match the whole string the pattern must be enclosed between the '
^' and '
$$' characters (as in the example above).
See Appendix Egrep Syntax for more information.