Instance Permissions Scope

[Ascherer17]

I observed something strange when working with Run Time Instance permissions on a Thing Shape and wanted to ask if this is expected behavior or a potential bug.  To demonstrate I'll propose a scenario.  I am using ThingWorx 10.0.

Created entities:

• TestUSR - User for testing access.
• TestTS1 - Contains property "TS1Prop" and service "TS1Service"
• TestTS2 - Contains property "TS2Prop" and service "TS2Service"
• TestTT - Template inheriting GenericThing template. Contains property "TTProp" and service "TTService"
• TestThing1 - Thing inheriting TestTT template. Contains property "ThingProp" and service "ThingService"
  

Now I configure permissions on TestTS1 only.  The rest of the entities will not have any permissions configured.

• Grant 'Property Read' and 'Service Execute' run time instance permissions to TestUSR.  See below.

Now I run Access Report for TestThing1 for user TestUSR.  This initially looks fine, but when I dig into the Specific Permissions by clicking the various run time attributes, I'm met with the following checkmarks and X's.

It appears that something is granting access to the "generic" Thing properties and services.  NOTE: I'm only showing a sample of specific service permissions below (left) since the list is long, and I also wanted to show the "Test" services' Denials.  

I confirmed that I don't have any Collection permissions active that provide any Grants.  

  

Next, I removed the 'Property Read' and 'Service Execute' run time instance permissions for TestUSR.

Running the access report again gave me the following.  No permissions are shown now.  This suggests that Granting Instance Run Time permissions (property/service) on my Thing Shape granted access to the "generic" properties/services on my Thing.  

Is this an expected behavior?  There are certain "generic" services that I may not want to grant to certain users.  

[Ascherer17]

I looked at the thing shape permissions screen again and just realized the "overrides" search box DOES provide the list of "generic" Thing Properties/Services/etc. for adding permissions here.  Has this always been the case?  

I understand that a Thing Shape has no purpose if it's not implemented on a Thing/Template, but shouldn't the "generic" properties/services that are not defined on the immediate Thing Shape still be "out of scope" in regards to permissions?

[slangley]

Hi @Ascherer17 

I think the feature allowing the "overrides" search box to provide a list of "generic" Thing Properties/Services for adding permissions was first introduced in ThingWorx 10.0. 

The following documentation in the Help Center may help to answer some of your questions:

• Thing Shapes Documentation
• Security Documentation

Regards.

--Sharon

[Ascherer17]

Thanks for the response.  It sounds like it is considered expected behavior.  The effect this imposes on Thing Shape development is that I will have to explicitly grant access to each individual Property and Service that I define on my Shape so as to not mistakenly grant access to the GenericThing properties/services that I wish to restrict (like "Delete" services).

I can understand the use case for using a Thing Shape as the vehicle for providing a certain list of "generic" attribute (property, service, etc) permissions to a specific group of Things.  However, it seems like it might be more appropriate to set those Run time instance permissions on a common Thing Template (TestTT in my example) that those Things will share since the "generic" attributes, coming from the GenericThing template, WOULD be in scope on the Template.