Roles and Access Rules
This is an overview page on roles and access rules. For more information on working with roles and access rules, see Roles and Access Rules Operations.
Who is an Administrator?
The term administrator in EJBCA designates any user with authenticated access to the CA or RA UIs. In this manual that encompasses the obvious cases such as CA Administrators and RA Administrators, but also includes other roles such as Auditors. An Administrator is identified by information of the client SSL certificate which they use to authenticate themselves with. This authentication is processed as follows:
During the TLS handshake with the application server, the issuer of the client certificate is verified with a list of trusted CA certificates known as the 'truststore'.
EJBCA verifies that the client certificate exists in the database, and may check that it's not revoked.
EJBCA tries to match the information in the certificate with any of the matching criteria found in the different roles. If matches are found in several roles, then the user will receive the collated rights. Any specific denials will trump approvals.
If a match is found, the access rules for this group is given to the administrator.
Administrator privileges is configured through Roles and Access Rules-page in the CA UI or by using the CLI. If you have locked yourself out of the GUI, the CLI can add another admin certificate to allow continued operations.
The following properties in web.properties affect how administrators are authenticated:
|
Property Name |
Description |
Default Value |
|
web.reqcertindb |
Require administrator certificates to be available in database for revocation checks. Set this to false, if you want to be able to use admin certificates issued by external CAs. |
true |
Roles
Administrators are given access rights based on what role(s) they belong to, and are identified by being members of that role.
Members are identified using a match value, of which there are three categories:
|
Match Value Type |
Possible Values |
|
X509 |
The full subject DN, any specific DN field or the specific serial number of their client certificate. For example, a specific administrator may belong to one role based on their common name (CN), and another based on their country (C). |
|
CLI |
The username/password of their end entity, but only available through the CLI. |
|
PublicAccessAuthenticationToken |
None, is used to give unauthenticated users access to the RA UI. |
Roles are also used for limiting access for other instances of EJBCA connecting over Peers, which allows separate RA instances to interface against the same CA agnostic of each other.
Note that any role meant for proxying RA operations over peers will be limited to a restricted set of access rules pertaining to RA operations, mitigating the consequences of an RA instance becoming compromised.
Namespaces
A concept in roles management is Namespaces, the purpose of which is to create a partition between sets of roles, in order to mitigate the risk of mistakenly assigning an administrator belonging to one organization to a role belonging to another.
Roles with editing rights to other roles will only ever see or edit other roles belonging to the same namespace, so it also allows for delegation of role administration, which is a typical use case of Managed PKI solutions.
For more information about working with namespaces, see Namespace Operations.
Access Rules
Access rules are used to authorize specific actions in EJBCA, ranging from activating crypto token keys to creating end entities to managing the access rules themselves. Access rules can be managed in two ways: either by setting them using one of EJBCA's Role Templates or by editing them manually from the comprehensive list in the advanced view. Often a combination of the two is used - a predefined template to start off and then fine tuning by giving or denying access to individual rules.
EJBCA Access Rules inherit the state from their parent rule by default, unless individually specified. Each access rule consists of the states Allow, Deny and Inherit .
Upon saving in this view the access rules are normalized, meaning that any specific rules that are redundant are simply set back to Inherit. The advanced mode also provides a summary view in order to verify what rules which have been set.
