Configuring Visibility and Permissions for ThingWorx Entities
In ThingWorx, there are two types of permissions:
• Design time—These permissions define which User Groups and Users have access to create, read, update, and delete entities.
• Runtime—These permissions define which User Groups and Users can access data, execute services, and trigger events on a Thing, which include Data Tables, Streams, and Users. You can set runtime permissions at a Thing, Thing Template, or entities collection level. The abstract entities, Thing Shapes, Data Shapes, and User Groups in the model do not have runtime permissions.
Visibility permissions define which Organization and organizational units have access to view an entity. If the members of an Organization or organizational units do not have visibility access, they are not able to view the entity in the entity list or search results.
It is recommended that you manage the permissions for your application as you build it. Implementing permissions at the end is very difficult.
Note that by default security checks do not allow an operation. If no specific permission is given to a user, then that operation is denied.
Avoid assigning unnecessary permissions to a group, as it might expose your application to unwarranted risks. You can use the override functionality to deny permissions on services that are available on the platform.
Recommended Workflow While Defining Visibility and Permissions for Entities
When you define visibility and permissions for entities such as Things, Mashups, and so on, the recommended workflow is:
4. Assign
visibility for entities based on Organization or organizational units.
5. Assign
permissions for entities based on User Groups or Users.
Use the following best practices while defining visibility and permissions.
Runtime Instance Permission for User Groups for All Things
Use runtime instance permission to assign permissions to User Groups for all Things that implement a specific Thing Template, rather than assigning permission to each Thing individually.
Import User Groups and Users Before Other Types of Entities
Collections may not be written as expected to the application if the corresponding User Groups or Users do not exist before you import From Thingworx Storage on the target server. To ensure that the permissions import properly, create the User Groups and Users in ThingWorx. Export the User Groups and Users from the system as an export file in binary or XML format. Then import them back into the same or new system, and finally import the rest of your model.
Import and Export of Collection-Level Permissions
Collection-level permissions for Things, Thing Templates, Logs, and so on, are exported or imported only when you export or import From Thingworx Storage. If you import or export From File, the collection-level permissions apply only on the entity level.
Reset the Default Administrator Password
Warning: It is critical to reset the Administrator password after your first login. If you do not change the default password, it can allow the system to be compromised in the future.