Skip to main content
K
khayes11-Visitor
1-Visitor
June 21, 2018
Solved

Thingworx Permission Hierarchy

  • June 21, 2018
  • 1 reply
  • 3973 views

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

Best answer by PaiChung

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.

1 reply

P
PaiChung22-Sapphire IAnswer
22-Sapphire I
June 21, 2018

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.

    K
    khayes11-VisitorAuthor
    1-Visitor
    June 21, 2018

    Hi,

    thank you very much for that, extremely helpful. Believe it or not I've been looking for a definitive answer on that for a number of months, there doesn't seem to be anything that explicit out there. Especially like the advice about entity creation, had lots of issues with that particular problem. Your solution is so much more elegant than mine 🙂 

    To sum up, all permissions are hierarchical and the system starts at the entity level and works its way back up to collection level. As soon as it meets a valid permission setting it stops and uses that permission setting. Permission settings at different levels are never combined. Is that right?

     

    I do have a couple of further questions if you don't mind?

    1. I'll use an example to illustrate the first. Lets say I have an entity with 4 properties. I want Group A to be able to read/write all four properties, but I also want Group B to be able to read/write property 3. If I give Group A read & write run-time permissions at the entity level how would I give Group B permission on property 3. My first thought was that I could add an override for group B on property 3, but would that not then negate the permissions I set at entity level, due to hierarchy, meaning that only group B could now read/write property 3?
    2. What is the difference between Design Time 'Update' and Run-time 'Write' - (at both template and instance level). Does the design time refer to property definition & the run-time refers to property value? I had assumed that design time permissions were for setting who could change templates etc in the composer, but then why would you have them for an instance of a template?

    Thanks again, as i said, really helpful answer. I'd say 70% of the problems we have come down to permissions.

    K

     

    P
    PaiChung22-Sapphire I
    22-Sapphire I
    June 22, 2018

    I'm glad I was able to help!

    Also just so you know, here with PTC we do offer an Application Security Design Rapid Outcome through our Customer Success group, so if you have a full fledged application going, this might be a great rapid outcome for you.

     

    Since you are assigning permissions specifically for a Group you are not overriding. So you can say: Group A all read/write and Group B overide read/write Prop 3

    Only if you combine the groups together would you get the scenario you are mentioning.

    BTW that is one way to approach a more complex security setup.

    Create a Read Group, Create a Write Group, Create an Execute Group

    or more specifically create an Operator Role Group, Manager Role Group, Supervisor Role Group

    Set permissions for those groups.

    Then let's say Factory 1 Group Engineers are then added to the Operator and Supervisor group

    and Factory 1 and Factory 2 Operators to the Operator group.

    (of course in addition you also need Visibility set up to have each group see their appropriate entities)

     

    Correct! Design time is the model itself, so in case of a ThingTemplate what Properties it has of what type, what services and what subscriptions. The actual Model or Design.

    Run time refers to at runtime being able to read/write a value, this would be incredibly rare for a template, but generally would be applied to the Thing level. i.e. I an change the Driver assigned to a truck, but you wouldn't be able to do that to a truck template. 

    This is also why we give the ability to do Runtime Instance Permissions on a Template because those will specifically apply to Things created from the Template vs. Runtime Permissions which would apply to the Template.

     

    Terms & ConditionsAccessibility statement