Saw this great question in the Developers forum https://community.ptc.com/t5/ThingWorx-Developers/Thingworx-Permission-Hierarchy/m-p/556829#M29312. Answered it there, copying it to here:
Question
Hi,
I have a few of questions regarding the permissions model in Thingworx. I can't find any documentation that explains it clearly. Hoping someone can help, or point me in the right direction for more in depth documentation.
-
My understanding is that permissions can be set at a number of different levels.
- Collection Level
- Template Level
- Instance Level
- Thing level
My question is, how do these levels interact with one another. Do they all get 'AND'ed together, or do those at the lower levels supersede the ones set at higher levels. e.g. If I set some visibility at collection level would this overridden by me setting a different visibility at say the Template instance level, or would both visibility permissions be valid.
- At each of level there is the ability to override (e.g. for a particular property or service). How does that fit in the hierarchy.
- I have read that in Thingworx 'deny' always supersedes an 'allow' permission. Is this still the case if I set deny at collection level and then at a lower level I gave 'allow' permissions would the deny take precedence.
- As far as I can tell 'Create' permissions can only be set at collection level. Does this mean that I am unable to restrict one set of users to create things of one template, and a different set of users to create another type of thing.
Thanks in advance for any replies
Answer:
Great question
Thing/Entity level permissions always take precedence
So if you set on Collection then on Template then on Entity it will first look at Entity then fill in with Template and Permission
So if Collection says can't do Service Execute
Template says Can execute Service 1 but not Service 2
Entity says Can execute Service 2 and leaves Service 1 as inherited
the end result is that the user can execute service 1 and 2
In Template and Entity you can find the Override ability, that is to specifically allow or disallow the execution of a Service or read/write of a Property
What is a BEST PRACTICE?
1. Give the System user all service execute on collection level
2. Give User Groups 'blanket' permissions to Property Read/Write on ThingTemplate Level
3. Give User Groups only Override permission to execute Services on ThingTemplate Level
4. Override User Group permission to DENY property read on potential properties they are not supposed to read on the ThingTemplate Level
Generally most properties all users can access fully and the blanket permission on a ThingTemplate is fine
It is very BAD to give user groups blanket permission to Service execute and should always be done by Override
Entity Hierarchy overrides the Allow Deny hierarchy, but within a single level (Collection / Template / Entity) Deny wins over Allow.
Create is indeed only set on the Collection Level, however the way to secure this is to give the System user the Create ability and create Wrapper services that use the CreateThing service which you can then secure for specific Groups. So you could create a CreateNewThingType1 and CreateNewThingType2 for example and give User Group 1 permission to Type 1 creation and User Group 2 permission to Type 2 creation.
Hope that helps.
