...

...

The Core API protects documents against access by unauthorized persons through a permission system. Each user has one or more roles in this system, giving them access to various documents for specified actions. The user-role - mapping manages the assignment of roles to users. In yuuvis® Momentum, this mapping is managed separately from the authentication process itself and can be configured according to the customers' needs. Furthermore, in the configuration of the yuuvis® AUTHENTICATION service, access conditions can be defined individually for each API endpoint.

Structure of the Permissions System

Anchor
RolesAndRoleSets RolesAndRoleSets

Roles and Role Sets

The permissions to access documents or to perform certain actions are assigned to specific roles. Users of the system are assigned to particular roles, and through those role assignments acquire the permissions needed—they become the owner of the roles. In general, roles are reusable groups of various permissions. Each role has a unique name and contains one or more permissions that are granted to the its owners.

Note: In the header of each incoming and authenticated API call, the roles of the corresponding user are included among other user-specific information. If you assign too many roles with long names to individual users, you might exceed the overall size limit of 8KB 8 KB for the header.

Permissions

Permissions denote access rights to certain objects and are assigned to a role. A permission consists of one or more actions and, optionally, a condition. The condition defines which objects are allowed to be managed by owners of a role with the permission, whereas actions define what procedures are allowed upon meeting the condition. In other words, if a user tries to access an object, the authorization system will go through that users user's roles to see if one of the conditions within his their permissions is met by the object. If the object meets the condition of one of the users user's permissions, the user will be able to work with the object according to the actions defined by that permission. 

...

Conditions

Conditions are statements in in the proprietary CMIS-based query language that that define the subset of documents in the system affected by a permission. If the condition for a document is met (meaning evaluating the query language expression returns 'true'), the owner of the role gets to access that document. For example, conditions can limit a users user's access to a specific type of object or hide documents that are older than a specific date. The conditions are appended applied to all requests from the role owner and thereby act as filters for the corresponding search results. 

Note: In a permission including the action create, the query function  CONTAINS()query function cannot be used in a condition. The whole statement would always be evaluated to as false even , even if the condition contains other sub-statements that do not use CONTAINS() and that would individually considered be evaluated to as true. Thus, it is not possible to specify a condition on the content of objects to be created.

The condition can also be left out - out – indicating that the permission applies to all documents in the system.

...

<!-- UsersThis withrole thisdoes rolenot aregrant notany allowedpermission to create, update or delete any object. -->
<role>
   <name>CAN_CREATE_NOTHING</name>
</role>

<!-- UsersThis withrole thisgrants rolecreation canpermission createfor any object. No conditions have to be matched. -->
<role>
   <name>CAN_CREATE_EVERYTHING</name>
   <permission>
       <action>create</action>
   </permission>
</role>

<!-- UsersThis withrole thisgrants rolecreation canpermission createfor objects that match the condition. In this case, only objects of type 'appTable:order' or 'appEmail:email' can be created. -->
<role>
   <name>CAN_CREATE_SOMETHING</name>
   <permission>
      <action>create</action>
      <condition>
         system:objectTypeId IN ('appTable:order', 'appEmail:email')
   	  </condition>
   </permission>
</role>

As of 2023 Summer, it is possible to specify conditions referencing the abac (attribute-based access control) section within the internal JWT (JSON Web Token). The following example role grants read permission for objects with at least one entry of the string list property appEmail:mailboxes contained in the current user's @abac.mailGroups string list within the JWT.

<role>
   <name>CAN_CREATE_SOMETHING</name>
   <permission>
      <action>read</action>
      <condition>
         appEmail:mailboxes IN @abac.mailGroups
   	  </condition>
   </permission>
</role>

...

The following endpoints are available for setting up and managing your tenant-specific permissions system:

• Retrieve the tenants tenant role set - GET /api/admin/permissions
• Update the tenants tenant role set - POST /api/admin/permissions
• Validate the tenants tenant role set - POST /api/admin/permissions/validate

...

• Retrieve the global role set - GET /api/system/permissions
• Update the global role set - POST /api/system/permissions
• Validate the global role set - POST /api/system/permissions/validate

Since version 2.4, yuuvis® Momentum has the ability to further structure the global role set into applications. This goes hand in hand with the usage of application schemata, as the new functionality is meant to exclude any role set entries related to an optional application schema from the main global role set.

...

To streamline the process of defining yuuvis® Momentum role sets, a number of REST endpoints are were made available to retrieve the current role set structures and to apply modifications. As seen in the permissions concept page, there are three options used to structure the role set, coming from two endpoint categories. The /system/permissions and /system/apps/{app}/permissions endpoints are both used to modify the global role set applicable to all users of the system, whereas the /admin/permissions endpoint serves to change the role set specific to the current tenant. 

...

<?xml version="1.0" encoding="utf-8"?>
<roleSet xmlns="http://optimal-systems.org/ns/dmscloud/roleset/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://optimal-systems.org/ns/dmscloud/roleset/ dmsCloud-roles.xsd">
    <role>
        <name>RoleEmail</name>
        <permission>
            <action>read</action>
            <condition>system:objectTypeId = 'email:email'</condition>
        </permission>
    </role>
    <role>
        <name>RoleDocument</name>
        <permission>
            <action>read</action>
            <condition>system:objectTypeId = 'document'</condition>
        </permission>
    </role>
    <role>
        <name>RoleEmailAndDocument</name>
        <permission>
            <action>read</action>
            <condition>system:objectTypeId in ('email:email', 'document')</condition>
        </permission>
    </role>
    <role>
        <name>AdminRole</name>
        <permission>
            <action>read</action>
            <action>delete</action>
        </permission>
    </role>
</roleSet>

>> The XSD for role sets: dmsCloud-roleSet.xsd.

Note: For the usage of the some Additional Services a fixed role set is required.
>> Defining Roles for Additional Servicesa Library-based Client

User-Role

...

Mapping

When users log in at the beginning of a session and are successfully authenticated by the identity provider, a JSON Web Token web token is generated in which the users' roles are listed under authorities. The GET user.info webhook is responsible for providing the users' roles. By customizing the webhook, it is possible to connect any access management provider delivering the users' roles in a suitable format. Per default, the webhook calls the ORGANIZATION service that is responsible for providing the role information.

To assign individual roles to the users of the system, an external identity provider is used, which takes over the responsibility for role assignment. Per default, the ORGANIZATION service reads the keycloak profile keycloak and thus requests the information from the identity provider Keycloak.

In order to run the ORGANIZATION service in Keycloak mode, the keycloak profile has to be activated and the following connection parameters in the profile  application-oauth2.yml profile are required:

• keycloak.server
• keycloak.admin.username
• keycloak.admin.password

Access Authorization for Endpoints

...

This article explained the role-based structure of the permission system provided by the Core API. The global and the tenant-specific role set can be changed via the corresponding endpoints. The user-role - mapping can be managed in Keycloak. The access authentication for individual yuuvis® API endpoints can be configured via the AUTHENTICATION service.

...