Access control

# Overview

Depending on the application’s use case, a need may occur to restrict access to particular capabilities of working with the documents. The CKEditor Collaboration Server provides a feature which allows to set specific privileges to a specific document for a particular user. The feature is a part of the token returned from the token endpoint. Thanks to that, the privileges are fully controlled by the application.

To make the managing of basic privileges easier, the CKEditor Collaboration Server provides three predefined roles: reader, commentator and writer. The roles have been described in more detail in the dedicated roles section of the Security guide. In case of need to create more specific roles, the CKEditor Collaboration Server allows to set particular privileges, which have been described in the Roles and permissions guide.

Keep in mind that privileges and roles are set separately for each user, so the logic of picking the right role or privileges must be implemented as a part of the token endpoint inside of the backend application.

# Examples

# Restricting document editing

Let’s assume there is a need to allow the user with ID user284 to only read documents named with the -read suffix. However, they should also be able to edit documents with the -edit suffixes. The example below shows what the token should look like for such a case:

{
    aud: 'your_environment_id',
        sub: 'user284',
        auth: {
                collaboration: {
                        '*-read': {
                                'permissions': [
                                        'document:read',
                                        'comment:read'
                        	]
                        },
                        '*-edit': {
                                'permissions': [
                                        'document:read',
                                        'comment:read',
                                        'document:write',
                                        'comment:write'
                                ]
                        }
                }
        }
}

In the example above, the *-read and *-edit properties represent patterns of document/channel IDs, so for the document/channel with ID my-document-read, the user with ID/sub user284 will be able only to read the document. However, for a document/channel with ID my-document-edit they will also be able to edit it.

With these permissions, the user with ID user284 will not be able to open any other document than the documents with matching *-edit or *-read document/channel ID patterns.

# Removing comment threads

There can also arise a need to create a user with privileges to remove whole comment threads created by other users in the whole environment. The user with ID user284 should be able to add comments as well as remove whole comment threads from a document, but should not be able to edit document content.

{
    aud: 'your_environment_id',
        sub: 'user284',
        auth: {
                collaboration: {
                        '*': {
                                'permissions': [
                                        'document:read',
                                        'comment:read',
                                        'comment:write',
                                        'comment:admin'
                        	]
                        }
                }
        }
}

In the presented example, the user with ID user284 can read all documents in the environment and comment them. Moreover, the user has the privilege to remove comment threads created by any other user, but they still cannot edit nor remove particular comments.

# Next steps

Read how to implement, configure and use the token endpoint.
Read complete guide on how to use user roles and privileges.