cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can change your system assigned username to something more personal in your community settings. X

Best Practice Thingworx Permissions

No ratings

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.

 

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Comments

Hey Pai,

 

What are your thoughts on Runtime Event Execute and Event Subscribe permissions? Are those permissions only related to dynamically generating events and subscriptions at Runtime? Or do they enable the User/Group to execute a custom event at Runtime?

Correct, events that are based of DataChange and Alert run in the platform super user context

For timer events you can specify security context

and then custom events you can provide specific security context

Version history
Last update:
‎Jun 21, 2018 04:18 PM
Updated by:
Labels (2)