...
| Page Properties | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||
Resources & Remarks Modification History
|
| Excerpt |
|---|
A yuuvis® Momentum user has to be authorized to the functionality of the system by assigning roles. For the individual roles, permissions can be set to allow actions on objects restricted by defined conditions where appropriate and the usage of specific endpoints can be controlled. |
...
create(as of 2021 Autumn) | permission to create new objects |
read | permission to know the about the existence of objects, to receive them in search results and to call various GET endpoints to a special object |
delete | permission that allows to delete objects content or metadata of objects for which also read permission is granted |
write | permission to update objects or to move the content of objectsobjects for which also read permission is granted |
Conditions
Conditions are statements in the proprietary CMIS-based query language 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 user's access to a specific type of object or hide documents that are older than a specific date. The conditions are applied to all requests from the role owner and thereby act as filters for the corresponding search results.
Note: In a permission including the create action, the CONTAINS()query function cannot be used in a condition. The whole statement would always be evaluated as false, even if the condition contains other sub-statements that do not use CONTAINS() and that would individually considered be evaluated 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 – indicating that the permission applies to all documents in the system.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!-- 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.
| Code Block | ||||
|---|---|---|---|---|
| ||||
<role>
<name>CAN_CREATE_SOMETHING</name>
<permission>
<action>read</action>
<condition>
appEmail:mailboxes IN @abac.mailGroups
</condition>
</permission>
</role> |
...