Authentication

Role & Rights Management

1. User Profile

RA Operators are able to modify the profile information by visiting the profile section of the MTG Certificate Lifecycle Manager Server application. The user profile tab contains information about the RA certificate of the user and provides the option of downloading the certificate.

RA Operators can choose their desired language between English and German. To change the supported language scroll down and in the bottom right corner select the application’s active language from the language dropdown.

Since version 2.0.0 RA Operators are able to view and update their profile information through their Κeycloak user profile. For more information see Keycloak Migration.

2. User Authentication

Since version 2.0.0 MTG Certificate Lifecycle Manager Server authentication is delegated to Κeycloak. The preconfigured authentication flow in Keycloak supports X.509 certificate user authentication, cookie authentication and username/password login. The certificates used for user authentication must be certificates signed by a CA trusted by Keycloak. In order to use RA Certificates produced from MTG CARA for user authentication, the MTG CARA RA Root CA must be trusted by Keycloak. Login with email and password can be activated per user by an Administrator from the Administration section.

Keycloak supports creating custom authentication flows to enable different authentication mechanisms. For further information about configuring a custom Κeycloak authentication flow see the following link www.keycloak.org/docs/latest/server_admin/index.html#authentication.

New user self registration is not supported yet. Users can be created by an Administrator from the Administration section.

3. User Authorization

RA Operators that are created independently of MTG Certificate Lifecycle Manager Server must possess the "RA ADMIN" in order to successfully login as described in MTG CARA Configuration. RA Operators with the "RA ADMIN" MTG CARA role receive the GlobalPermission "ADMIN".

Permissions can be added or taken away from an RA Operator using the MTG Certificate Lifecycle Manager Server UI and/or REST API.

3.1. Permissions

MTG Certificate Lifecycle Manager Server uses a fine-granular permissions system, where an RA Operator (user, or an API Client) can receive individual permissions for specific operations (such as READ/UPDATE/DELETE) for specific resources (such as realms, policies, end entities, certificate requests, certificates). For instance, if an RA Operator has PolicyPermissions READ and CERTS_READ for a specific policy, this would give them permissions to read the policy and any belonging certificates, but they won`t be able to modify or delete the policy (requires UPDATE and DELETE permissions respectively) or use it to create new certificates (requires CERTS_CREATE permission).

Whenever an RA Operator creates a new resource, the application makes sure that they receive at least a set of permissions on it, so that they are able to see and use it.

  • For a realm: [FULL_READ, UPDATE, DELETE, ENDENTITIES_CREATE, POLICIES_CREATE];

  • For a policy: [READ, UPDATE, DELETE, CERTS_CREATE];

  • For an end entity: [READ, UPDATE, DELETE];

  • For a certificate request: [READ];

  • For a certificate: [READ, REVOKE].

In addition to any explicit permissions, users and API clients always have implicit READ and partial UPDATE permissions to themselves in order to allow for functionality such as updating an email address or resetting a forgotten password.

For more information regarding the different groups of permissions look into the Permissions section of the [ApiDocumentation].