Permissions are granted in the application exclusively via roles. The roles assigned to a user are controlled via external user management. A role always belongs to a tenant. More about tenants here. When the application is started for the first time, the system creates a default tenant with three associated roles. These roles are ssu-user, ssu-admin and ssu-root. If necessary, additional roles can be created or existing ones can be modified.
The role ssu-root should not be changed or deleted without first creating another role with similar permissions. Otherwise, there is no longer any way to obtain higher permissions (ssu.server.*).
Rights
Rights are structured hierarchically and organised by points. All rights begin with the prefix ssu. An asterisk * at the end of a level includes all subordinate rights. Example: ssu.* covers all rights in the namespace ssu. If an existing level is subsequently subdivided, the previous right is implicitly deemed to have been concluded with * in order to maintain compatibility.
Certain rights require other rights in order to be exercised. This is also taken into account in the hierarchy. Thus, the right ssu.user.documents.sharingcases implies the prerequisite right ssu.user.documents.
The following rights exist:
|
Right |
Effect |
|---|---|
|
|
Allows authentication in the system. |
|
|
Allows documents to be persisted in the database. |
|
|
Allows individual documents to be shared directly with users outside the system. |
|
|
Enables the use of workflow functions. |
|
|
Allows a user to manage their own document types. |
|
|
Allows a user to manage their own user settings. |
|
|
Allows mouse input for handwritten signatures. |
|
|
Allows touch input for handwritten signatures. |
|
|
Allows electronic pens for handwritten signatures. |
|
|
Allows the use of signotec signature devices for handwritten signatures. The installation of the signoPAD-API/Web is required for the use of the marking devices in a web environment. |
|
|
Allows the use of click-to-sign for signing. |
|
|
Allows the use of qualified signatures using sign-me. |
|
|
Enables the user to perform operations on behalf of other users of their own tenant. Which operations these are depends on your own permissions from the group For example, a user with the rights |
|
|
Allows management for document types of your own tenant. |
|
|
Enables the management of user settings defined by your own tenant. |
|
|
Allows the management of roles for your own tenant. |
|
|
This right behaves identically to |
|
|
Allows management for document types of all tenants. |
|
|
Enables the management of user settings defined by tenants across all tenants. |
|
|
Allows the management of roles for all tenants. |
|
|
Allows the management of tenants in the system. This includes creating, modifying and deleting, as well as the premature creation of users. |
Roles
Rights are never assigned individually in the application, but are always grouped together by roles. Roles can be managed either via the pool application or the REST API. Management here means that a name can be defined for the role and the rights it contains. There are restrictions on the granting of rights in order to prevent an undesirable escalation of rights. Defining roles in your own tenant requires the right ssu.tenant.roles and allows you to assign rights from the groups ssu.user.* and ssu.tenant.*. The ssu.tenants.roles right, on the other hand, is able to define roles across tenants and is also not restricted in the assignment of rights.
The default roles
The following roles are automatically created when the application is started for the first time.
|
Role name |
Permissions |
Description |
|---|---|---|
|
|
|
This role has permissions for all user functions and is intended for use of the application as a normal user. |
|
|
|
This role is intended for administrative purposes. This allows you to view and modify the user data of all users of the default tenant, as well as their documents and settings. |
|
|
|
This role is intended exclusively for the system operator. In addition to all cross-tenant access, it may also perform sensitive operations, such as creating tenants. |
Performing operations on behalf of other users
With the permissions ssu.tenant.users and ssu.tenants.users , it is possible to act on behalf of another user. Operations of this type can be tracked in the audit logs.