Roles and Access Rules
This overview page on roles and access rules provides information on the general concepts. For more information on how to work 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 user interfaces. This includes CA Administrators and RA Administrators but also other roles such as Auditors. An Administrator is identified by the information of the client SSL certificate used for authentication. 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 are given to the administrator.
Administrator privileges are configured via the 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 the 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. The following match value categories are available.
|
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). |
|
OAuth |
Match with JSON Web Token (JWT) claim. Valid claims are Subject, Issuer, or Audience. The OAuth Provider must be trusted by EJBCA, see OAuth Providers. |
|
CLI |
The username/password of their end entity, but only available through the CLI. |
|
PublicAccessAuthenticationToken |
None. 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 about RA operations, mitigating the consequences of an RA instance becoming compromised.
Namespaces
A concept in roles management is Namespaces. Namespaces are used to create a partition between sets of roles, to reduce 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 Access Rules list in the advanced mode. 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 the Advanced mode the access rules are normalized, meaning that any specific rules that are redundant are set back to Inherit. The advanced mode also provides a summary view to verify what rules have been set.
