ThingWorx provides a very granular security model. There are two sets of permissions, one for design time and one for run time. The design time permissions are for managing who is allowed to modify the model (create, read, update, and delete entities), while the run time permissions determine who can access data, execute services, and trigger events on a Thing (which includes data tables, streams, and users). Controls for security and permissions are located under the Security section and menus in Composer.
For each permission, you can explicitly permit a user or group to be able to do something, for example, edit a Thing, or explicitly deny a group the ability to do something, such as not allowing the Users group to edit a Thing. You can apply permissions at the group level and at the user level. An explicit denial of a privilege always overrides a privilege grant. Note that security checks default to not allow an operation. If no specific grant has been given to a user, then that operation will be denied.
The design time permissions are for standard CRUD operations (create, read, update, delete) on any entity. They control the model definition and who can make changes to the model. These permissions can be applied to individual entities (read, update, or delete a specific Thing, Thing Shape, Data Shape, etc.), or they can be broadly applied to an entire entity collection (create, read, update, or delete Things, Thing Shapes, Data Shapes, etc.). If you apply permissions to the collection, you can override, add, or reduce those permissions at the individual entity level.
The run time permissions apply to all entity aspects, such as property read, property write, event execute, and service execute. Run time permission overrides allow reduction of permissions for specific aspects, such as properties, services, or events.
You can set run time permissions at a Thing, Thing Template, or collection level. A collection is a group of Things or Thing Templates, and permissions on a collection are inherited by all items in that collection. You can also set run time and design time permissions at the individual Thing Template level, and all Things derived from that Thing Template inherit those settings. All inherited permissions can be overridden at the individual Thing level.
The abstract entities within the model do not have run time permissions. These entities include Thing Shapes, Data Shapes, and groups.
If the corresponding users/groups do not exist before you import from ThingworxStorage on the target server, collections do not get written as expected. To assure that the permissions import properly, you must create the users and groups in ThingWorx. Create an export of your users and groups, import that, and then import the rest of your model.
Collection-level permissions (Things, Thing Templates, logs, etc.) export or import only when you export to ThingworxStorage or import from ThingworxStorage. If you import or export from file, the collection-level permissions only apply on the entity level.
Was this helpful?