User Group privileges for a secure web integration

When integrating with CHILI publisher, you will need to define the user rights for the technical user for your API calls. This is an important step to secure your application and to prevent unwanted API calls.

To understand which rights or priviliges need to attributed to your technical user, you'll need to fully understand the security model and the way the editor and web services function.

CHILI publisher client-server architecture

As with any client-server architecture, CHILI publisher has client-server communications.

• Clients
  • CHILI publisher editor
  • CHILI publisher backoffice
  • Custom applications (like your website, or a Switch server, or any integration)
• Server
  • CHILI publisher web services

The CHILI publisher clients like the editor and backoffice are usually also ran at client machines; your or your customer's laptop or desktop computer. Because the editor is a browser-based online editor, and the same applies for the backoffice.

This means that the CHILI publisher web services are reachable from client machines, often located in different parts in the world using non-secure connections. And this fact is the main reason to take user privileges (and thus security) serious. If your application is providing editing options to the consumer via a public website, then the CHILI web services will also be publicly available so the editor can interact with the server. This could be directly accessible, or indirectly when for example using a reverse proxy.

It is recommended to protect your application by using HTTPS and by protecting the reverse proxy (when using one) that forwards web service calls to CHILI publisher with OAuth 2.0 or some other security protocol to prevent unwanted access from external users. To prevent unwanted access from known users (users logged in into your application, but trying to manipulate CHILI publisher directly) it is best to use user groups to limit their rights within the CHILI publisher environment they are connected to.

CHILI publisher User Group privileges

User Groups provide a privilege-based security model within a CHILI publisher environment. That means that privileges can be attributed to user groups, such as:

• Read privilege for Documents
• Add privilege for Assets
• Edit privilege for Documents
• Browse privilege for PDF Export Settings
• Add privilege for Users
• Edit privilege for User Groups

As you can see, these privileges include administration privileges that you probably do not want to expose to the public users. Especially those last two examples of privileges could be pretty dangerous.

User Groups can be created and managed via the back office application:

CHILI publisher User settings

Once a user group is created, it can be attributed to a user via the backoffice application:

Using multiple User Groups

CHILI publisher groups are cumulative and use the least restrictive privileges.

To illustrate this, let's consider the following example:

• Group A
  • All rights on Documents
  • No rights on Assets
• Group B
  • No rights on Documents
  • All rights on Assets

If a User 1 is part of both Group A and Group B, then User 1 will receive the combined rights of Groups A and B, in other words: it will have all rights on Documents and Assets.

Using the 'Enforce rights on API'

When using user groups, it is important to also enforce the rights on the API.

To explain the use case of this option, it's important to understand that this is an improvement to allow for a more secure configuration. This option was not available in the beginning and therefor it also not activated by default, as we are always striving for backwards compatibility.

Historical background on default behavior

The editor has quite a lot of panels, toolbars and functionalities that trigger web service calls to the CHILI publisher server, for example:

• DAM Feed panel: browses the assets on the server
• Save button: saves a document back to the server
• Snippets panel: browses the documents on the server
• Inserting an image: Reads the image from the server
• Uploading an image via a variable or panel: Adds a new image to the server
• To output a PDF, we chose a PDF Export Setting from a list: Browses and Reads PDF Export Settings from the server
• ...

There are also a couple of minimal rights needed when using the CHILI publisher editor, they are listed later on this page.

If we want to use the full editor capabilities we'll have to attribute a lot of privileges to our users. To facilitate customers, the Design privilege on Documents (needed for being able to open the editor) was invented. When a user has this privilege, they will have all other necessary rights on other resources for the editor: Add, Edit, Delete, Browse, Info, ... on Documents, Assets, Fonts, PDF Export Settings, ...

This made it easy to customers to do quick integrations, but it lacked possibilities to secure the web services better, since the web services would allow any Add, Edit, Delete, ... web service calls from that same user. This makes it vulnerable for users with bad intentions.

The enforce rights solution

By creating this checkbox, CHILI publisher allows you to keep the legacy less-secure behavior for your old applications, but at the same time it allows customers to secure their applications better when they are ready for it. By checking the checkbox, the CHILI web services will explicitly check if the user has the needed privileges for the web service call.

What's the catch? Well, you'll need to list all the possible actions that your user will be doing with the editor:

• Will you use the DAM Feed panel?
• Will you allow new images to be uploaded in your image variables and/or DAM Feed panel?
• Will you use the Snippets panel?
• Will you output PDFs with the Output Panel or the Toolbar button?
• Will you allow the Save As functionality?
• Will you allow users to add Fonts from the server?
• ...

All these questions need to be answered before you can decide which privileges are needed for your technical users.

Minimal privileges needed for an editor to open

When opening the editor, a couple of web service calls are always made and so the following rights are always needed when using an editor.

• APIkeys
  • Info
• Assets/BarcodeTypes/DataSources/DocumentConstraints/DynamicAssetProviders/FoldingSettings/ImageConversionProfiles/ImageTransformations/ThreeDModels
  • Info (When used in the document)
• Documents
  • Edit (to be able to save)
  • Design (to open the editor)
• Fonts
  • Info
• SpellCheckDicts
  • Browse
  • Info
• ViewPreferences
  • Info
• Workspaces
  • Info

The list above mentions all minimal privileges needed when opening an editor, but as you enable panels and tools within workspace, more privileges will be required.

Something more on Browse rights (and Add and Delete)

Browse rights allow to search or list resources. That means that they could be used to list all the resources on the server. Since CHILI publisher uses a privilege based security model and not a more fine-grained model such as ACLs (Access Control Lists), it is not possible to limit access to certain resources or certain folders. If a user has the privilege to browse a resource type, they can call the web services to list all of the resources.

This means that this right is a bit tricky: it is almost indispensable in any application to have browse rights; e.g. to let the user browse in a particular folder to change an image in the document. At the same time, if browse is allowed then it's just a matter of calling the correct web service to list all the resources in that environment.

So how can you cope with this if you store multiple customers' documents and images in one environment? You could use a different user with more privileges in the back-end to execute critical web service requests there. The back-end credentials and API keys should never be exposed to the front-end.

In other words: you'd create a front-end user with front-end privileges (no browse, no delete, no add, ...) and a back-end user with back-end privileges. The front-end user is used to generate API keys for the CHILI publisher editor and for previews in the front-end application. The back-end user is used for your back-end code that could be securely exposed to your front-end via your own web service. Exposing your own web service will allow you to implement custom security rules and checks whenever needed.