Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X
I have Thing, where I keep services and properties for my application.
I want this services to be available for every user, so for this Thing I've set Permissions for group Users, with Property Write Allow, Service Executable Allow, but Property Write Deny.
I have also some additional user A*, who is allowed to change properties, so for him I've set Property Write Allow, Service Executable Allow, and Property Write Allow.
Finally, settings for User groups are treated as higher priority and this user is treated like Property Write set to Deny.
How to cope it without creating extra group of users, including All the users, but not A?
Or is there a way to create a group, that I will create today and all existing users except A, but will in future included all users added later?
*this is virtual user to be used via timers, so datas are refreshed.
Solved! Go to Solution.
Permissions setting is complex and tricky. You can use Permissions->Access Reports to query which access privileges a user has on an object. This might help you tracking it down. Some other privilege are giving access, maybe also check Collection Permissions.
When you set the properties through a service, it could also be the service is executed with System privileges (see "System User Example").
The spec I quoted was directly from the product help.
It's a bit hard to understand what you did because you mention "Property Write" twice for each line.
But A, like any user, is always in group Users automatically.
Also, documentation states "An explicit denial of a privilege always overrides a privilege grant."
Therefore, when you allow access to the group Users, but deny it to User A it should be denied to A if there are no other privileges in effect.
But if there is no explicit denial of the access the access for A should be working, and group Users would not have access, because documentation says "Note that security checks default to not allow an operation. If no specific grant has been given to a user, then that operation will be denied."
Yes, that's my mistake, first Property allowance is for Property Read, not property write. But reading your answer I see you understood this case well.
Ok, let's forget about Property Read & Service Executable, here is easy case, because it must be always Allowed, that's simple case.
But what about Property Write? It should be Denied for all Users except UserA. And it should be allowed for UserA only.
Can I create group which include all users except UserA? Group, where every new user will be added every time user created? Group that does not need to be administrated manually?
Or somehow set permissions that UserA will have higher permissions than standard User?
I haven't tried this scenario myself, but what I'm saying is:
User A is always in group Users. Security checks default to not allow an operation, i.e per default Prop Write should be denied for everyone (including group Users), without explicitly setting it.
When giving User A Prop Write privilege, A has Prop Write access because it is the only explicit privilege assigned.
So if you just set the privileges for group Users on Prop Write back to "inherit" (or better, delete the whole entry for the group), you should be fine.
On your other idea, a group where every new user will be added, you would probably have to use a Scheduler or Timer to check the user list regularly, or have the groups assigned via Active Directory.
Created new user, UserB. Default user, did not add him to any group, organisations, etc. Set my timer to work with rights of userB.
1. Property Write set to inherited for users group, Allow for User A - timers are still working, properties are written by timer no errors in log. Acc. to your proposal, if timer run with UserB allowances (so Property Write inherited, as for Users Group), I should have error in logs, and datas should not be refreshed.
2. Deleted whole line of Users group in Thing permission. Only permissions for UserA kept - timers still working, data refreshed. Web interface still working for other users - so mashup calls services & read properties inside Thing, even if users different than UserA neither UserB logged. That's really suprising for me, because if only UserA is mentioned in permissions, then how does it allow other users to run services and run properties? In your first reply I find quote which says - if nothing is mentioned, it should be denied.
Permissions setting is complex and tricky. You can use Permissions->Access Reports to query which access privileges a user has on an object. This might help you tracking it down. Some other privilege are giving access, maybe also check Collection Permissions.
When you set the properties through a service, it could also be the service is executed with System privileges (see "System User Example").
The spec I quoted was directly from the product help.
Looks like collection was the reason for such behaviour.
Still do not know how to solve my issue, but ok, first I have to dive deeper into subject before I will be able to continue this discussion.
Thanks for your advices,
I've tried myself now and this worked for me:
Default installation, no additional collection permissions set.
Created UserA, UserB.
Created Timer1, Run As User UserA. Set runtime permissions on Timer1 for UserA to Allow Event Execute, Event Subscribe.
Create Thing1 with service update(). Set Visibility to Everyone.
On Thing1 add Runtime privilege "Service Execute","Property Read" to Users.
On Thing1 add Runtime privilege "Property Write" to User A.
->Timer, Subscription and service execution works for User A.
->User B can call the service, but since the service updates the property and UserB does not have PropertyWrite, the service fails.
Later you can go more fine-grained by using Property, Service, or Event Overrides but I suggest you get that working first.
Yes, the "trick" basically is to never (never say never, but really rarely this is needed) use Deny permissions. In your case, having only "inherited" property write permissions for a user group will result in a Deny (as no inherited Allow exists). But for your group/user which has explicit Allow permissions it will work.
The "trick" is I'm learning by doing, so will need to get more experiences to meet situation where that would be so important.
Do you know any good link permission issue will be well explained?
Looks like TWX had good DEVELOPERS page, but when I found it, there was info PTC is going to close this service, so I had no time to learn from there.
I would always recommend to run another (local) dev/experiment/learning server where you can do those experiments and are not tied to the preconfiguration of your projects. And you can reset the server in case the experiments fail or you want to start from scratch. Especially with privileges you want to avoid side effects when adding/removing permissions, In most cases these instances are included in the license.
The contents of developers.thingworx.com (or parts of) were moved to this community when it was closed, so you can try searching in IoT>IoT Tips.
Maybe this one helps? https://community.ptc.com/t5/IoT-Tips/Configure-Permissions-Guide-Part-1/ta-p/809422