Roles and Permissions

400
Roles & Rights Management

Roles are business units that contain one or more permissions and can be assigned to CLM users or API clients. For example, a role can be configured to contain the permissions required for a specific operation, such as certificate creation or revocation for a policy. The role CLM_ADMIN, which contains the ADMIN global permission, is always present in MTG-CLM.

Creating Roles

In order to create a valid role, a name and one or more permissions are required.

Role Information

The Name field is mandatory during role creation.

Permissions

MTG-CLM uses a fine-granular permissions system, where an RA Operator (user or 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).

Scenario Outcome Extras

RA Operator has PolicyPermissions READ and CERTS_READ

also has permissions to read the policy and any belonging certificates

cannot 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 e-mail address or resetting a forgotten password).

For more information regarding the different groups of permissions refer to API Permissions.

Notes and limitations

  • The name of each role must be unique and start with prefix CLM_. Roles that do not have that prefix are not considered MTG-CLM roles and cannot be viewed and managed using MTG-CLM.

  • Roles are stored and managed in Keycloak application.

  • The default CLM_ADMIN role cannot be edited or deleted using MTG-CLM.

  • CLM_ADMIN role can still be deleted using Keycloak UI. It is advised against it. However, if the CLM_ADMIN role gets deleted in Keycloak you may create a role with the name CLM_ADMIN using Keycloak UI.

  • Renaming a role in Keycloak will result in MTG-CLM perceiving it as deleted. The renamed role can be viewed in MTG-CLM, but no permission will be associated with it.

  • On startup, along with CLM_ADMIN, a role KC_ADMIN is created, which can be assigned to a Keycloak user that needs ADMIN access to it. The aforementioned roles are associated with each other but still work independently.

  • Any default realm role can be edited and deleted like any other role.

  • Realms that were created before default realm roles were introduced, get assigned roles on startup via migration scripts, except from realm SYSTEM. Since SYSTEM realm is not meant to be used with API clients, which is the sole use case for default realm roles, this is the only realm that does not get assigned a default role.