Thingworx Permission Hierarchy

[khayes1]

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

[PaiChung · Accepted solution]

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.

[khayes1]

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

[PaiChung]

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.

[khayes1]

Hi,

thanks again for getting back to me, appreciate the help. If I've got this right you are saying that if you use an override for a different group other than those which have already been used at a higher hierarchical level (i.e. entity or template etc.) then the permissions are effectively ANDed. Only if you use the same group will it take precedence? So if I use the examples below .

Assuming that at instance/entity level I have assigned run time read/write allow on all properties to Group A then:

Example 1:

Group A given Read/Write allow at instance level

Group B given Read/Write allow on property 3

means both groups A & B can read/write property 3?

Example 2

however, should I want only Group B to be able to read/write property 3 then I would add 2 overrides

Group A  property 3 deny read/write

Group B  property 3 allow read/write 

Thanks again for your help with this, really helpful as there doesn't seem to be much out there explaining how the hierarchical levels interact. Not sure how much influence you have :-) but It would be really useful if there was something. Especially if it had examples that showed the different combinations people might wish to use including deny/allow overrides. Do you know if something like that already exists (& I just missed it).

I think once we understand the rules then we should be able to implement a secure system.

That said I will look into using the Customer success group. Thanks again.

K